Enterprise Architecture is a young, immature discipline that produces models to guide the development of an enterprise. It is generally recognised to date back to the late 1980s or early 1990s and the work of Zachman, Spewak and others though it really took-off in the late 1990s and early years of the 21st Century.
But methodological disciplines do not emerge complete and well-formed from nowhere. Spewak’s Enterprise Architecture Planning, for example, builds on and incorporates some of Michael Porter’s thinking on the analysis of enterprises and industries. [Sadly, some more recent EA methodologies seem to have forgotten about this very solid foundation.]
Enterprise Architecture is not the only, nor even the first, discipline to take a model-based, methodological approach to the change and development of enterprises.
“Systems Thinking” may be considered Enterprise Architecture’s older, and perhaps somewhat wiser, big brother.
“Systems Thinking” as a very broad ‘tradition’ in analysis and model-building dates back to the 1960s although its origins lie in the focus on efficiency and effectiveness of post-WWII industrial enterprises made possible by new technologies. It is, I think, no coincidence that this was a time of great social, economic and technological change – that demanded new ways of looking at the world, and the linkages between changes happening in it, and the new possibilities opened up by the changes.
Today, several renowned enterprise architects would identify “Systems Thinking” as the proper theoretical basis for the practice of Enterprise Architecture.
For example, James LaPalme and Donald de Guerre identify Enterprise Architecture as “Open Socio-Technical Systems Design” – a particular application of Systems Thinking. [Lapalme, J. & de Guerre, D.W., (2013), “An Open Socio-Technical Systems Approach to Enterprise Architecture” in Gøtze, J & Jensen-Waud, “Beyond Alignment: Applying Systems Thinking in Architecting Enterprises” (http://www.amazon.com/Beyond-Alignment-Applying-Architecting-Enterprises/dp/184890116X/ref=sr_1_1?s=books&ie=UTF8&qid=1415365247&sr=1-1&keywords=Gotze+Beyond+Alignment)
With hindsight developed in recent years within the Systems Thinking tradition, it can be seen as comprising three distinct broad categories of methodology or theory: “
- Traditional Systems Engineering” (TSE) – also loosely known as “Hard Systems (Thinking)” (HST),
- “Soft Systems (Thinking)” (SST) and
- “Critical Systems Thinking” (CST).
Gerald Midgely identifies these categories as the first, second and third waves of “Systems Thinking” [ Midgley, G., (2000), “Systemic Intervention: Philosophy, Methodology, and Practice”, Kluwer Academic / Plenum Publishing – from the Contemporary Systems Thinking series. ] and very roughly they cover the periods 1965-1980, 1980-1995 and 1995-present respectively.
There are many variations and ‘subdisciplines’ within these broad categories – like Cybernetics, System Dynamics, and Critical Systems Heuristics and so on – but before outlining the key features of each category, we need a little more clarity about terms like “System”, “Methodology” and “Method” – as these words have been so mis-used in recent years as to lose their precise meanings.
What is a “System”?
A system is any identifiable collection of parts or components that interact with each other and with things that are not “in the system”.
This simple idea has some profound consequences. To be counted in or out of the system means the parts are defined by being an identifiable whole or unity in their own right. Thus a part can be anything – and it does not necessarily have to be a material thing.
So it makes sense to talk of “knowledge systems”, “learning systems”, “information systems”, “social systems” and “organisational systems”etc. – all of which may feature components that are not material objects. Even physical systems may feature elements that are not material objects – magnetic fields, energy, physical space or spacetime, other sorts of fields, information, and ‘causality’.
Since systems are themselves identifiable wholes, they may also be parts of ‘larger’ (in some sense) systems. This leads immediately to notions of relative systems hierarchy and strata, or layers, with subsystems and families of systems – and composition/decomposition, specialisation/generalisation and the ‘black-box’ and ‘white-box’ systems.
Since individual people and organised groups of people are identifiable as wholes they also may be components in systems – hence social systems.
As components may be counted in or out of “the system” there is an ‘analytical boundary’ between the system, as modelled, and the environment.
Since analysis, or observation, is the product of theory-based cognition and empirical perception there may be a ‘real-world’ boundary around the system components – or it may be the boundary is only in people’s thinking.
The pattern of interactions within the system, or between the system and its environment, may endure over time – which leads to ideas of structure in and between systems.
Or the interactions between components and systems may involve the fairly rapid movement of material, energy or information – which leads to ideas about system dynamics.
Hence the very simple, general notion of a “system”, with a proper definition, bootstraps or kickstarts a whole theoretical framework for looking at the world – or bits of the world labelled as “enterprises”.
One key observation from this way or looking at the world: the real-world is full of thousands or millions of different systems and individual parts may be components in many systems concurrently.
‘Natural Systems’ emerge from the plethora of interactions between components without any conscious intervention but artificial systems emerge when purpose and design are inscribed into the relationships between components by human agency – these are ‘Engineered Systems’.
So the general notion of “System” – that is the one underpinning Enterprise Architecture as a discipline that holistically models the components and relationships in enterprises – is very different from the narrow notion of “Computer System”, “Software System” or “IT System” – that underpins IT Engineering – though consistent with it.
What is/are “Method(s)”?
A method is a collection of related actions engineered to achieve a purpose.
The actions may be cognitive-theoretical actions – like identifying and labelling things, putting things in categories, identifying types of things, describing the relations between things, assigning purpose to things etc. or practical-physical actions like moving something from one place to another, changing the shape or configuration of some thing or system, initiating a chemical or physical reaction – like putting a match to the bonfire, or flipping an electrical switch – and so on.
The actions are related to each other in time and space – they may be in a simple linear sequence or an iterative loop – or maybe a set of contingent pattern-action ‘reactions’ – lists of “ if this pattern, event or perception should occur then take that action”.
Methods may be applied to any human purpose – and in Enterprise Architecture that purpose is to produce a relevant model to direct the change.
Methods comprising cognitive-theoretical actions are generally called “analytical methods” whereas those concerned with making change in the real world, including constructing shared, explicit models, are generally “methods of synthesis”.
Academics may confine themselves to ‘pure’ (uninformed-by-practice) analysis but in real-world practice analysis and synthesis are invariably mixed – and so are their methods.
We continually iterate and alternate between analysis and synthesis – or thinking and doing.
The key thing about methods is that they are tested and known to work (proven) – use the method and you get the result you want – assuming an appropriate level of skill and judgement is used in applying the methods.
Don’t use methods and you risk wasting your time, effort and resources and falling short of objectives and expectations.
Note also the significant relationship between “Method” and “Process” – each implies the other.
As to “Methodology”, I agree with Midgley: “a methodology is the set of theoretical ideas that justifies the use of particular method or methods” – and it should be carefully distinguished from method or methods (see Chapter 5 of Midgley’s book.)
[In passing, it may be observed that many so-called methodologies available to the prospective practical interventionist or change agent (such as an Enterprise Architect) are somewhat weak in the theory that justifies their methods.]
Turning back to “Systems Thinking”, TSE or Hard Systems Thinking is founded in the philosophical ideas of reductive realism and positivism: that complex phenomena can be understood by being broken down into the behaviours of individual components and their relationships and interactions. TSE assumes that components obey a strict deterministic, linear causality – that if certain “initial conditions” occur, then the prescribed outcomes inevitably follow.
The traditional method of “Functional Decomposition”, widely used in Enterprise Architecture, is firmly in the TSE camp – it may even be at the heart of it – ironically since “function” is a human construction and non-material attribute imparted to components and systems (and not something derived from the teleology-free material world).
Traditional Systems Engineering may be thought of as mapping straightforwardly onto the technological systems analysis part of Enterprise Architecture.
The problem with TSE (alone) is that it does not apply to people intensive systems – which do not follow such a mechanistic causality.
This realisation led to the development of Soft Systems Thinking – which focuses its attention on the systemic and systematic way in which the ideas of different stakeholders in a “problem-situation” – i.e. a situation that at least some stakeholders want to change – are brought together (with the intention of achieving some consensus about change actions).
In this sense Soft Systems Thinking is more attuned to sociological, not technological systems and leans towards a “social constructivist” philosophy – like that underpinning the Social Construction Of Technology theory. [http://en.wikipedia.org/wiki/Social_construction_of_technology].
SST methods and methodologies include Strategic Assumption Surfacing and Testing (SAST), Ackoff’s Interactive Planning (IP) and Soft Systems Methodology (SSM).
Not only do SST methods map onto Enterprise Architecture’s methods and techniques for the analysis and synthesis of social systems in an enterprise, they also inform and illuminate EA methodology itself.
SSM provides a passable and somewhat justified model of social construction of enterprise models –that is of Enterprise Architecture.
One important methodology that may be counted as a part of the second wave of Systems Thinking is Socio-Technical Systems (STS) theory – which bridges the social and the technical aspects of enterprises.
Critical Systems Thinking (CST), the third wave, is about applying the right sorts of methods of systems analysis (and synthesis) in the right contexts (or change-situations).
It is “critical” in two senses: 1) it examines the assumptions and ideas behind the methods and 2) it involves critique and “critical thinking” about the situation and the methodologies that may be chosen from. CST is therefore inherently “multimethodological”.
“System of Systems”
Arguably the best-known of the CST methodologies is the System-of-Systems Methodology (SOSM) developed by Jackson, Keys, Flood and others.[http://www.bcs.org/upload/pdf/steve-clarke-paper.pdf ]
However, the term “System-Of-Systems” (S-O-S) needs to be used carefully:
In one context it may refer to systems of systemic methods – as in Jackson et al.’s SOSM;
In another it may refer to the stratified and partitioned reality of many sociological and technological, natural and engineered systems with shared components interacting with each other.
Some enterprise architects hold the conviction that Enterprise Architecture is synonymous with Enterprise Systems Engineering (http://en.wikipedia.org/wiki/Enterprise_systems_engineering) – e.g.James Martin
[ See “Transforming the Enterprise Using a Systems Approach” in Gøtze, J & Jensen-Waud, “Beyond Alignment: Applying Systems Thinking in Architecting Enterprises” (http://www.amazon.com/Beyond-Alignment-Applying-Architecting-Enterprises/dp/184890116X/ref=sr_1_1?s=books&ie=UTF8&qid=1415365247&sr=1-1&keywords=Gotze+Beyond+Alignment).
In my view it depends what you mean by “Enterprise Systems Engineering”.
If you mean Traditional Systems Engineering applied at an enterprise scale and scope, then I’d have to disagree. That was tried before, it didn’t work then, it doesn’t work now and the world has moved on.
If, on the other hand, you mean something more like Enterprise System-Of-Systems Engineering (http://en.wikipedia.org/wiki/System_of_systems_engineering) – with both critical multimethodological and engineered enterprise senses of S-O-S – then I am in complete agreement.
For this reason, in my view a broad grasp of several strands and sub–disciplines of “Systems Thinking” is an essential and significant part of the Enterprise Architect’s armoury of methods and methodologies.
If your EA Team doesn’t have at least one person who has studied Systems Thinking, are you missing out on good, methodological practice?
© Ian Glossop, Glossop Mallard Consulting Ltd., 2014. (November)
Enterprise Architecture, as an activity in organisations and ‘discipline of praxis’, is about producing rigorous, explicit models of the enterprise to be used in the organisation’s decision-making processes. Its purpose is to enable the organisation to make better decisions about where to invest its precious resources to change the enterprise for the better. [Note: The “Enterprise” and the “Organisation” are different things – but the differences between them are unimportant for this article.]
That investment might be in new or improved IT systems, or new products and production processes – or in new or improved capabilities in the organisation.
An enterprise – any enterprise – has many facets or aspects to it – social and technical – and there are many ways of metaphorically looking at it. In academic jargon, there are several (cognitive, theoretical) ‘lenses’ that might be used to analyse an enterprise. If Enterprise Architecture is done well, several of those lenses will be used and each analysis will contribute something valuable to the models produced.
The job of the Enterprise Architecture team is to pull together these different analyses, through different lenses, into a coherent whole that can be used, by various people throughout the enterprise, to plot and plan the enterprise’s evolution.
The single most popular, and oldest, ‘lens’ through which people have analysed enterprises might be called “Functional Decomposition”. This is about examining the activities in the enterprise as “black boxes” – focussing only on what it is the enterprise, or some “Organisational Unit” within the enterprise, does – and deliberately ignoring the how of its doing. It is based on the very old tradition of “the Division of Labour” or “Functional Specialisation”, which many people trace back to the very early 20th Century and the management thinking of F.W.Taylor. Others, however, would trace it back even further – and there is no doubt Adam Smith presented a clear idea of it in his “Wealth of Nations” [Book 1, Chapter 1] in 1776 with his “pin-making” example. [Yes, Enterprise Architecture was being done over 200 years ago – but of course it wasn’t called “Enterprise Architecture” then.]
Functional decomposition – and the structuring an enterprise around the functional decomposition – remains popular with management teams and enterprise architects even today. Indeed, it has become so ubiquitous, so commonplace and habitual that managements may even do it unconsciously – without thinking. Nobody would even think to question the existence of a separate “Accounting Function” – and organisational division or unit dedicated to carrying out that function.
The traditional organisational structure – Operations, Marketing, Finance etc. – is a reflection of the high-level functional decomposition of the arbitrary (commercial) enterprise. [This is one reason why novice enterprise architects and inexperienced managers sometimes mistake ‘function’ for ‘organisation’ or vice versa – and sometimes don’t fully appreciate ‘function’ in abstract terms, or produce an organisational model when asked to produce a functional one.]
Almost every enterprise architecture description would necessarily include a functional (and organisational) perspective. There may even be a ‘view’ dedicated to just the functional decomposition hierarchy,depending on the methodology used. In the analysis of modern enterprises the functional view is often traced through into the technical architecture – in the functions of software components, or robots, or other machines – as well as the teams of people. The relationship between functions and organisational units may be described by an “interaction matrix” or “dependency matrix” – again depending on the methodology used. [ This is, of course, not possible if managers fail to distinguish properly between functions and organisations (units) – which is one reason for adopting the method. ]
However, most enterprise architecture teams would argue that a functional view alone, or even a functional and organisational view, is far from enough. A functional decomposition and an organisational decomposition are necessary parts of an enterprise analysis and model – but not sufficient to enable rational decision-making instead of unconscious conformity to an historic model. Others argue that “… executives need to re-think the concepts through which they have classically viewed the firm.
Describing the organization as a set of sequentially ordered parts no longer captures its essential properties. In its place they need to use a dynamic and integrated model …” [Laszlo, E & Laszlo, C. in “The Insight Edge – An Introduction to the Theory and Practice of Evolutionary Management”]. An enterprise architecture model?
A fuller and richer enterprise architecture model would include some other abstract aspects of the enterprise (than functions). An important, related lens would be the capabilities of the enterprise – things the enterprise, or parts of it, are able to do. TOGAF – The Open Group Architecture Framework – DODAF – the [US] Department of DefenseArchitecture Framework and MODAF – the [UK] Ministry of Defence Architecture Framework, among others, include notions of “Capability”, “Capability Architecture” and “Capability-based Planning”.
This capability ‘lens’ is also not new – though not quite as old as functional decomposition. About 20 years ago it developed from the “Resource-Based View of the Firm (RBVF)” – and saw firms, commercial enterprises, as distinguished by their portfolio of capabilities rather than the assets they happened to own or control.
Ironically this was about the same time that Enterprise Architecture as a separate, distinct discipline was also being developed. Spewak published his seminal book on “Enterprise Architecture Planning” in 1992.
Dorothy Leonard (later Leonard-Barton) in her book “Wellsprings of Knowledge” produced a taxonomy of capabilities, and what Enterprise Architects would now call a “Reference Model” for a capability that asserts it comprises Physical Systems, Managerial Systems, Skills and Knowledge and Values – and is surrounded by a ‘learning system’ that makes the capability dynamic – change over time. [Contrary to the common misconception, not all EA Reference Models are reference models for technological systems.] She also warned about “Core Capabilities” turning into “Core Rigidities”.
A couple of years later David Teece and colleagues developed the “Dynamic Capabilities Theory” – as a model of how enterprises innovate and adapt – and ensure their competitive survival. About the same time the Oxford economist John Kay developed his “Distinctive Capabilities Theory” published in his “Foundations of Corporate Success” book.
This theory argues that what sets an enterprise apart from would-be copy-cats, and makes it successful, is its “distinctive capabilities” – and these derive from three sources:
2) Reputation and
Kay’s Distinctive Capabilities Theory recommends itself as a method to formulate strategy – strategy that if successfully executed would lead to sustainable corporate success.
So it would seem that identifying the enterprises distinctive capabilities, its core capabilities, its enabling and supplemental capabilities and actively managing their development individually and as a portfolio is really important to successful execution of the strategy.
An explicit Enterprise Architecture model, featuring As-Is, To-Be and Transitional Capabilities Architecture – linked to and coherent with other architecture models like Functional and Organisational – is therefore an essential product of an Enterprise Architecture initiative.
Ian Glossop, Enterprise Architect.
(Copyright – September 2014 – Ian Glossop, Glossop-Mallard Consulting Ltd.)
10 March 2015
What is a good elevator speech for Enterprise Architecture?
I usually say something like the following:
“Enterprise Architecture is a strategic business capability that provides benefits to a business for:
- Digital strategy exploitation
- Cloud strategy implementation
- Business and IT Consolidation
- Business Transformation
- Cost reduction
- Business Process Improvement and innovation
- Exploiting opportunities for value creation
- Facilitating Investment decisions
- Effective performance measurement & management
- New organisation structures
- Business Model changes
- Mergers & Acquisitions integration
- Achieving and facilitating business growth
- Improving the efficiency of existing operations
- Smarter systems
- Reuse of shared services
- New technology implementation
- Managing Regulatory changes”
If the building has a large number of floors then I might elaborate as follows:
- For most companies Enterprise Architecture is an essential business capability when embarking on a large scale strategic planning and business transformation, which is all about staying robust, viable and efficient, continuing to deliver good outcomes and value to its customers/consumers in the future.
- Enterprises want to stay competitive and efficient and beat the competition. EA makes the connections between Strategic Decisions and Business Outcomes and ultimately to deliver Value to their customers and stakeholders.
- If a company is to succeed, it must make strategic decisions and investments in change based on a thorough analysis that is only possible with enterprise architecture.
- All components of the Enterprise Architecture are traced back to the Business Strategy, Goals, objectives, Mission, Vision etc. This enables full traceability for changes.
- EA provides an overall framework and knowledge base for managing, designing and delivering strategic business and IT changes, aligning outcomes to strategies, ensuring successful business transformations.
- The Enterprise architecture model is a knowledge base for understanding, analysing, conducting impact and gap analysis, in order to evaluate various strategic scenarios.
- EA helps to inform critical issues such as cost reduction, identify problems, process improvement, identify innovations, technology selection, investigation of possibilities and opportunities, organisation design, performance management, mergers and acquisitions and new business models.
- EA guides, recommends and oversees the realisation of business strategy.
- EA supports the assessment of future investment decisions.
- EA supports Impact Analysis by identifying the boundaries and main components of an enterprise architecture and how they interrelate.
- EA identifies the high level factors that describe the ends and means for achieving the enterprise mission and the architecture vision.
- EA helps to aligning the IT Strategy with the Business Strategy, Business Model and Business Operating Model.
- EA provides value by governing and supporting IT enabled policy changes, major initiatives and change programmes.
- EA provides a knowledge base to directly support business and IT management leadership in understanding what makes the business work.
- EA provides governance and design assurance to service development and delivery projects.
Pick and Mix to suit your organisation !
5 August 2014
Business transformation involves significant changes to all areas of an enterprise. It focuses on the future strategies.
These includes strategies, business models, operating models, business processes, information & data, systems, products, business services and channels. These are exactly the deliverables developed by enterprise architecture to understand the current state of an enterprise, to envision and design the future state of the enterprise, to discover the gaps between them, to identify the opportunities for investment in change and to plan the enterprise architecture roadmap to achieve the change initiatives.
This sounds just like what Business Transformation approaches do, doesn’t it?
In fact Enterprise Architecture and Business Transformation disciplines have much more in common, than they have differences.
It’s clear that real Enterprise Architects play a critical role in business transformations. The Chief Enterprise Architect is the most important member of the senior management team leading a business transformation and ensuring that it is effective.
By the way Enterprise Architecture, by definition, should not be misunderstood as only being about IT Architecture or Technical architecture, used just to support IT solution development. This is not what real enterprise architecture is for. Business transformation is rarely limited just to IT projects.
The CxOs are the business leadership responsible for providing business direction, identifying the needs for the business transformation in the first place and making the investment decisions. But the Enterprise Architects will work directly with the CxOs to drive out the devil in the details, planning the future transformation roadmap, developing future scenarios, making projections and forecasting future options. Acting without enterprise architects is equivalent to failing to make proper preparations and is asking for trouble. The enterprise architects perform the important task of analysis and evaluating the impact of strategies and proposed changes in detail, identifying risks and prioritising the transformation initiatives into a viable roadmap. They manage the complexity of transformations and are essential to achieving success and effective transformational changes. Enterprise architecture is about bridging the gap between the transformation vision and strategy and its realisation.
What approach should be taken for leading business transformation?
The recommend approach is based on the books by John Kotter, “Leading Change”, “A Sense of Urgency” and The Heart of Change Field Guide”, together with real enterprise architecture approaches to managing strategic change.
Creating the conditions for business transformation
1 Increasing urgency
For Business Transformation to be successful, then the whole enterprise needs to understand the need for it. The whole enterprise needs to have a view of the current state and the motivation for change. Enterprise Architecture provides an understanding of the existing problems and the desired future vision. Avoid complacency and business as usual behaviours. Business transformation means new behaviours and new ways of working.
2 Building a joint Enterprise Architecture/Business Transformation team
A Business Transformation team should not be a group isolated from the enterprise architecture team, but completely integrated with it. Remember that a real enterprise architecture team is responsible for the future business change within the enterprise (and is not just an IT development function), typically up to between 2 and 5 years into the future. Seriously, how can they be kept separated from a business transformation programme?
Identify the members of the Enterprise Architecture/Business Transformation (EABT) team. Look for a mixture of strong management leaders and include a good influential people from a continuum of all job titles, levels of authority and statuses. Remember that enterprise architects are strong and effective change leaders and already cross cut the whole enterprise. Non-enterprise architects in the EABT team will probably have greater political and financial skills whereas Enterprise architects will have cross domain knowledge about the whole enterprise in detail, analytical skills and significantly greater modelling skills. All team members should have good vision and leadership skills.
Hold honest and convincing discussions, dialogues and workshops. Enterprise architects are often useful as facilitators at this stage.
Ask for emotional commitment from all EABT team members and commitment to work together for the common good of the enterprise.
3 Establishing the Target Transformation Vision models and Strategy
What does business transformation success look like?
Planning the strategies and confirm the business motivation. Enterprise Architects and C-level managers will use a Business Motivation Model for this, identifying Strategies, Goals, Objectives and performance measures.
Analyse the various ideas and options to develop an understanding the various Business Models for the target transformed enterprise. Alternative business models can be produced by the enterprise architects using a Business Model Canvas approach and these can be compared with multiple measures, including total cost of ownership and potential revenue.
Avoid thinking in terms of systems and IT solutions too early, after all this is the job of the enterprise architects later on and business transformation is a business problem. Allow for unfettered innovations to emerge from discussions.
Identify stakeholders including customers, partners and suppliers.
Examining the Outside In views from the perspective of these customers and partners.
Creating detailed Business Scenarios, Customer Journeys and Partner Journeys using any suitable story telling approach. Remember that stories are powerful, especially if they come directly from your customers. The enterprise architects will capture and analyse these business stories, but remember that at this stage these are not detailed IT requirements or user stories/use cases from an Agile software development perspective. Those kinds of deliverables will be defined much further downstream.
Identify opportunities and innovations. The team should consider approaches such as a Blue Ocean Strategy (see the book).
Definition the transformation Vision, Values, Motivations.
Defining the transformed value propositions
Analyse and understand the risks, their probabilities of occurring and their potential mitigation.
Engaging and enabling the Enterprise
4 Communicating the Transformation Vision and strategy
Communication is essential for all business transformations if they are to be successful.
There will be detractors and strong opposition to some of the transformation vision. The enterprise architects in the EABT team will ensure that fact based decisions can be made.
Publish and communicate the business transformation models as widely as possible. This will help make the right decisions and solve problems. Don’t assume either the C level managers or the enterprise architects have a monopoly on good decisions. Challenges need to be addressed and responded to.
Obviously some aspects of the transformation vision and strategy will be commercially sensitive and should not be communicated to the competition without careful thought. However, ultimately remember that the enterprise will want support from all customers, internal stakeholders, outside stakeholders, partners and suppliers and this support and buy in cannot be won without communication. Talk often and modify the transformation visions as needed. The enterprise architects will keep track of alternatives and decisions in the transformation model. The Vision and strategies need to be tied back to all aspects of the transformation model. This becomes infinitely easier using a flexible EA management tool (such as ABACUS) and avoiding spreadsheets and Visio diagrams which rapidly become unmanageable.
Ensure that the joint Enterprise Architecture/Business Transformation (EABT) team is able to lead by example by speaking about the transformation vision at any time and to always evangelise about it.
5 Enabling Action
Enabling transformation change is about removing the barriers to change and empowering staff. It involves removing resistance. Often resistance to change from staff is tied to functional divisions and people who are not measured by enterprise’s transformation success but only by fulfilling their own their own personal goals. Paradoxically, it may be the way they are measured and rewarded by the C-level managers that causes people to resist and avoid supporting transformational change.
To enable the right actions, the authorities, responsibilities and rewards need to be re-aligned with the business transformation vision, goals and objectives.
It is the enterprise architect who takes the business strategies and business model and successfully realise them on behalf of the whole enterprise, so are often best placed to also identify the authorities and responsibilities needed to focus people on benefits to the enterprise.
Ensuring that the Enterprise Architecture /Business Transformation (EABT) team has the right authority is also essential, and is able to resolve competing priorities. This authority is also exercised in relation to the governance and compliance stage.
Establish the appropriate metrics and measures, and maintain a scorecard for the business transformation vision, goals and objectives. It is strange how often performance is ignored and enterprises do not know how to measure success, or align performance to desired outcomes. Costs and revenue need to be balanced with other measurement dimensions. Measures should be aligned to transformation changes in the EA management tool.
6 Define Investment Opportunities
Examine the investment opportunities and develop an investment case. The Enterprise Architects will be best placed to determine how realistic and feasible a specific investment opportunity will be, and determine the fine details. Whereas the C-level management will understand the balance of costs and revenue developed in the Business Model.
Enterprise Architects will use a Business Capability model to scope and plan which business capabilities will be modified by a transformational change.
Transformational changes will typically be classed as short term or long term changes. However by definition, transformational changes will tend to be large and disruptive rather than “low hanging fruit”. Short term transformational changes will however be useful for maintaining the transformation momentum across a number of iterations.
Changes to business capabilities are identified as a number of capability increments. The dependencies between these and their priorities will form the first draft enterprise architecture roadmap and provide the scope and context for subsequent change iterations.
Implementing and sustaining the business transformation
7 Keep up the momentum
It is important to keep up momentum for a business transformation. The EABT team must keep communicating and clarifying the business transformation changes.
The business transformation model must be regularly published and all opportunities taken to speak to all stakeholders about it and inform them on status and progress. Capture feedback and responses to continually validate the vision and measure its effectiveness.
Address the fear, uncertainty and doubt from detractors and sceptics and motivate supporters to evangelise about the transformation. Encourage desired culture and values that reinforce the transformation changes. Keep your eyes on the roadmap and don’t assume everything is done after the success of the first iteration and let performance and concentration levels drop. Don’t let the EABT team get diverted into other side projects. Perseverance is important. Remember that change is the only constant.
Develop communication material including web sites, brochures and posters. Posters can be very effective as information radiators.
8 Enterprise Architecture Governance and Compliance
C level managers will be making the investment decisions and providing funding for investments in change.
Establishing an enterprise architecture governance and compliance capability will ensure successful realisation of transformation changes, and help them become permanent business as usual.
Detractors will often try to derail changes but the formal governance and compliance approaches will enforce decisions made but will also provide a platform for challenges and objections to be discussed openly and objectively.
9 Realising Transformation Changes
Business transformation needs many kinds of potential future changes to occur, not least of which are the key cultural changes and organisational changes.
Business Process changes, Information changes, system changes and procurement changes are also important. However for these I recommend designing for flexibility and adaptability not going for a fixed solution which may be cheaper but will invariably be difficult to change the next time. Business transformation should be thought of as a continuous process, enabling an enterprise the rapidly respond to changing forces in the market environment.
Before changes are executed, it is a good idea to conduct a Change Readiness Assessment, if you have not already done this earlier in the Enabling Action stage. This will help find out how prepared the enterprise is for the transformational changes and identify the enterprise’s overall competence, knowledge, skills and capabilities. Any shortfalls will be addressed by planning suitable skills training, and addressing the shortfalls.
For maximum success in strategic business transformations, an enterprise needs to completely and fully use their enterprise architecture resources and enterprise architects. You have to work hard and plan carefully. Building the proper foundation with an enterprise architecture model for the scope of the business transformation will make everything very much easier.
There is no good reason why real Enterprise Architecture and Business Transformation should not be merged as a single discipline. The skills needed for each hugely overlap, especially the Business Architecture domain of enterprise Architecture.
A joint Enterprise Architecture Business Transformation team is essential to achieving successful and viable transformations.
11 November 2013
I was reading this today:
8 August 2013
I’m reading a great new book called Intersection: How Enterprise Design Bridges the Gap Between Business, Technology, and People by Milan Guenther
The book discusses modern Enterprise Architecture perspectives like the Outside In approach and provides a holistic design lead approach that is focus more on the customer than on the underlying applications, technology and infrastructure.
The book also addresses the corporate branding of an enterprise. A successful brand is grounded in the strategic future vision of an enterprise. This strategic vision is also what drives the enterprise architecture initiatives, so it is clear that the enterprise architecture discipline must then provide the key support for understanding what contributes to the brand, what makes the brand successful and what must be done to sustain the brand. This is a refreshing perspective that tends to get lost in most organisations.
The knowledge of messages, business events, interactions with stakeholders, outside in scenarios, business services and value streams that are defined and designed as part of the business architecture domain will all enable senior executive to understand and develop their brand. A brand is not just the value proposition, the set of products and services offered, but includes the development of the reputation of the enterprise, the customer experience it provides and the trust the customers develop. The book describes this in terms of the form, appearance, communication and behaviour of the enterprise and much more
Enterprise Architecture will have a profound impact on the brand and ultimately on the financial success of the business.
This book is a must read that should be on the bookshelf of every true Enterprise Architect.
27 June 2013
The Enterprise Architecture team has a lifecycle of its own, but doesn’t operate in a vacuum. The Enterprise Architecture capability fails if it is seen too much as blue sky thinking in an ivory tower.
The Enterprise Architecture team will interact closely with all the other management processes in an organisation, especially the IT management processes. When all these processes work together effectively, an enterprise will be able to successfully manage strategic changes and drive business transformation effectively and efficiently. Often in organisations little thought has been given to the integration of the EA processes to the other management processes. This contributes to making the EA team into an ivory tower, seemingly unconnected with everything else. The aim of this post is to shine some light the EA lifecycle and its interactions.
One of the goals when establishing or maturing an enterprise architecture capability is to make sure that the enterprise architecture a fundamental and normal part of the business-as-usual decision making flow rather than considered as an afterthought.
Too often I have seen major changes apparently started directly at the project initiation phase before there has been any serious appraisal of the business fit, technical fit and feasibility of that change undertaken, not least by the enterprise architects.
The Enterprise Architecture capability is driven by understanding the business strategy and strategic scenarios which drive the business and IT enabled changes in an organisation. It is there to ensure that any strategic change is viable in the future, but it also identifies the dependencies, feasibility, risks, issues, costs, and informs the subsequent investment decisions that need to be made.
The current state and future state enterprise architecture models will be developed (typically using the TOGAF ADM).
In the EA roadmap, the strategic changes will be prioritised and arranged into a meaningful sequence to inform the decisions made by the programme and project portfolio management and before any projects are initiated.
The Enterprise Architecture capability will govern what parts of the future state enterprise architecture are developed and delivered by the projects, and thereafter ensure that the delivered solutions and services remain compliant with it. The compliance stage will also capture and approve any innovations that are identified as useful. The enterprise architecture team and/or a technical design authority will provide design assurance for the projects, to ensure that principles, standards, patterns, policies and guidelines are being followed.
It’s worth noting that the EA lifecycle is not a part of the project solution development lifecycle as many organisations seem to imagine it is, but is a separate lifecycle that operates in parallel at a strategic level. Neither is the EA lifecycle the same as the TOGAF Architecture Development Method.
After a solution has been delivered, the enterprise architecture team will harvest the results in order to update the current state enterprise architecture, to measure performance and to publish a dashboard for the senior management team.
The following diagram illustrates the major stages and processes that are undertaken by an Enterprise Architecture team, for each iteration they undertake.
These Enterprise Architecture processes can be best understood in the wider scope and context of all the processes defined by the COBIT5 framework for the governance and management of enterprise IT. http://en.wikipedia.org/wiki/COBIT http://www.isaca.org/cobit/pages/default.aspx
I’m surprised that COBIT is not used more in UK based organisations, but it is more popular in Europe. I would recommend COBIT5 is used as a broad framework for assessing the risk and value of IT and the governance of all IT management processes.
The following view is broadly based on the COBIT processes, and illustrates the position of the Enterprise Architecture processes relative to the other IT management processes identified by COBIT.
Starting from the Strategy & Vision there is an overall clockwise cycle through all the processes. The Enterprise Architecture capability is responsible or accountable for the processes shown in red, and is consulted and informed about the other processes. The responsibilities will, of course, vary in each organisation and in many cases the enterprise architecture team will be additionally responsible with many more of the Solution Development processes (for example, Select, Acquire, and maintain COTS software products).
In a more mature enterprise Architecture environment, all these processes will be expected to consume and contribute to the knowledge, information and models held in the Enterprise Architecture repository (illustrated in the centre of the diagram). The management dashboard of performance metrics, charts and graphs will be generated from the EA repository.
The above diagram is based on the COBIT processes. The latest version of COBIT5 is more explicit about enterprise architecture than earlier versions were. The following table shows the COBIT5 processes that directly relate to or are supported by an Enterprise Architecture team and an Enterprise Architecture Governance Board.
|APO03||Managing Enterprise Architecture|
|APO02||Define Strategy (in this context this usually means the IT strategy)|
|APO04||Manage Innovation (via the Enterprise Architecture Governance Board)|
|BAI08||Manage Knowledge (via the EA Repository)|
|BAI06||Manage Changes (i.e. Strategic changes and IT enabled Business changes that drive the future state enterprise architecture)|
|MEA03||Monitor and assess compliance with external requirements (via the Architecture Governance Board)|
|APO05||Manage Portfolios (with EA Roadmap)|
|APO011||Manage Quality (via EA Appraisals)|
|APO012||Manage Risk (via EA Appraisals)|
|EDM01||Set and Maintain Governance Framework|
|EDM02||Ensure Value Optimisation|
|EDM03||Ensure Risk Optimisation|
The following table shows who is Responsible, Accountable, Informed or Consulted in regard to the services provided by the Enterprise Architecture team and an Enterprise Architecture Governance Board.
Implementing the EA lifecycle and integrating it with the IT management processes in an organisation will help the Enterprise Architecture capability to avoid the challenges and misperceptions that it is some kind of ivory tower that can be wilfully ignored and disbanded when looking for budget cuts.
Senior management teams will instead come to appreciate the valuable contribution that Enterprise Architecture makes to strategic planning, appraising investments in change, driving business transformations, finding opportunities and innovations, and to understand the value EA has to the organisation as a whole.