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.
24 June 2013
How often do you see customer journeys, customer events and scenarios modelled in an Enterprise Architecture model? Not often, if at all I suspect.
In my opinion, the ‘Enterprise’ in Enterprise Architecture should include all those stakeholders that are engaged with an organisation. This include all those suppliers and service providers to the left hand end of the Value Chain, and the Customers at the right hand end. In this post I’ll be focusing on the Customers that are consuming the products and business services that are the outcomes of the Value Chain.
This is the view that the Customers have from the outside of an organisation looking in. This perspective should drive what a business does.
In most organisations however, the Enterprise Architecture is usually focused on the organisations internal workings, the inside out view of how an organisation can become more efficient, leaner and reduce cost, as a way of making more profits. The focus is on delivering better software faster, improved processes, commoditised infrastructure, reusable IT services, providing a self-service internet to replace face to face contact with the customer and so on.
The business strategy may look at the customer and market segments and the drivers for strategic change, but this is often as far as it goes. The rare organisation models the customers journey and the customers perspective and if they do then its rare to find the customer journey modelled in the Enterprise Architecture.
Organisations often try to reduce the direct interaction they have with their customers by removing phone numbers from their web sites, and providing limited set of services and FAQs. Customers are forced to waste many minutes on the telephone, selecting endless options in an attempt to get a human voice to speak to. Companies are afraid of this because of the costs of complaint handling. To be fair, a number of organisations have implemented a live chat IM service on their web sites and high value customers do often get a live account manager to speak with. But what about the rest of us everyday customers? It still seems like businesses are lacking a good understanding of their customers behaviour.
Digital Businesses and Digital Customers
Every business is now a digital business. It’s the same for customers (i.e. all the consumers, customers, potential customers and contacts) who are also increasingly digital using technologies like smartphones, social networks and broadband. They are using their own devices (such as iPads and other tablets) to research potential products and business services that they wish to purchase from businesses. They browse social networks and conduct searches to determine what product or business service best suits them. They have mass access to huge networks of information such as Google to help them.
Customer behaviours are changing, but does your enterprise architecture model know that? Does it model what the customers’ own processes are? Does it model the events that originate from a customer? Does it model what the various scenarios that there are in the customer journey? In my experience the answer is typically ‘No’ to all these questions. In my experience even when an organisation is modelling the customer journey then it is never included in the future state enterprise architecture.
What is the customers’ processes? Customers will conduct a search and discovery process, engage with the business to select, negotiate and make a purchase. If the business is lucky then the customer will re-engage to make future purchases, but if they screw up the customer will get annoyed and tell all their contacts on social media about why they are no longer buying. Companies are seeing the increasing power of customers but how many are trying to understand them and model their behaviours?
Enterprise Architecture, or more specifically, the Business Architecture within the Enterprise Architecture discipline should cover the customers’ interactions with a business, understand what they are saying on social media.
An initial approach is to speak with customers and use a thinking framework such as VPECT to determine their Values, Policies, Events, Content, Trust Relationships.
They can also use the less engaged PEST analysis for strategic market research.
Results of conducting VPECT analysis and PEST analysis should be recorded in the enterprise architecture models and associated to a representation of the customers journey
How should we model the Customer Journey and the different customer scenarios?
For a start, each scenario in a customer journey will be triggered by one of more of the Events discovered by VPECT analysis and be concluded by something of Value delivered back to the customer (Content).
What does the Event trigger? For me the best representation is a sequence of Business Services, in what might be called a Service Flow diagram.
This is much the same as a Process Flow diagram but from the external perspective. For a customer interacting over the internet, the Business Services might involve a Browse Service, A Product Detail Service, A Product Price Service, A Payment Service and a Fulfilment and Delivery Service. The Outside In service flow view is later mapped to the Inside Out process flow view
It’s easy to see that an organisation may not itself directly provide all these Business Services (for example the Payment Service may be provided by PayPal or similar, and the Fulfilment service may be provided by DHL or similar)
What also need to be modelled are the Customers own goals and objectives and how the scenario of service based interactions supports the customers goals. Key measures should also include:
- How much did the customers have to invest in the interaction (in time, and navigating complex interfaces, breaks in the interaction, confusion) to complete it?
- How much they enjoyed the interaction (customer satisfaction feedback)?
- How many customers abandoned the attempt early?
- How many customers complained to their social media contacts afterwards?
- How many customers complained directly to the business?
Another question that needs to be addressed is what channels and multiple channels do customers use? Customer these days are much more likely to use multiple channels at different times, rather than just a single one:
- Search the internet with their iPad or smartphone at home
- Switch to using their desktop PC at work
- Use the telephone, email, IM message or SMS message for clarification on product details, prices and discounts
- Hand off the desired purchase to their purchasing department to use corporate discounts to make the actual purchase
- Expect an email or letter with their receipt, complemented by an SMS message to their mobile device and copy to the purchaser
Channel strategies don’t often allow for a customers’ use of multiple channels and for account information being passed around during an interaction with the customer. Businesses often manage different channels with different functions and organisation units. This results in confusing and frustrating transfers between departments. How often have you called a business, given your contact and customer account details, only to be handed off to another department who asks you all over again for that same information? It’s extremely annoying and it’s this kind of symptom that undermines the customers’ experience and sends them tweeting negative remarks.
One to One marketing
One-to-one marketing refers to marketing strategies that are designed as if they apply directly to an individual customer. Information is collected about customers’ needs, customer segments that they fall into, their preferred channel, their lifetime value to the business and which products and business services they are likely to purchase.
See the books by Don Pepper and Martha Rogers: The One to One Future and the One to One Field book.
What one-to-one marketing misses is more of an Outside In perspective, going much further in understanding the values that a customer needs and their own processes that customers follow (formally or informally).
The book I recommend is ‘Outside In: The Power of Putting Customers at the Center of Your Business’ by Harley Manning, Kerry Bodine et al.
Total Unified Customer Communication
Typically organisations still tend to communicate with their customers in a disjointed and unconnected way. Invoices, statements, receipts, marketing literature, pricing deals, discounts, marketing campaigns, letters, emails, IM messages, data streams etc.. are all sent from many different departments who have no idea about the incoming or outgoing communications that have already been received or are being made by other departments. The result is customer confusion. To be fair, the situation is not so bleak for business customers, as it is for individual personal customers, but increasingly it’s difficult to tell the difference and negative social media discussion will also impact the business customers.
Instead of just silo based incoming communication with customers we need to get a total view of all the customers interactions both incoming and outgoing to the business, and within social media, centralising all interactions, via multi channels, with a Customer Communication Management (CCM) system. Curiously I’ve never seen a Customer Communication System in any future state Enterprise Architecture model and the recommendation to include one has fallen on deaf ears. One to one marketing should become one to one multi-channel total customer communication.
Companies will want to differentiate their products and business services and to compete with other businesses and therefore they will need to innovate. Understanding their customers’ perspectives and their customer journey scenarios will be a key innovation for any business. This will require that the future target Enterprise Architecture model includes these views and connect them to the rest of the model.
16 June 2013
As Business Capabilities are directly derived from the corporate strategic plan and are designed to satisfy the enterprise’s business strategies, goals and objectives, so they provide an excellent basis for the creation of an Enterprise Architecture Roadmap.
What are Business Capabilities?
A Business Capability represents the ability of an organisation to perform an activity that results in an outcome of value. Business Capabilities are as far as possible expressed in terms of those business outcomes and value. As far as I know the concept originated from MODAF and was later adopted by TOGAF. See http://en.wikipedia.org/wiki/Capability_management_in_business
Many Enterprise Architects and organisations fail to really use them, but in fact they are slowly becoming a common EA deliverable and a way of developing a target operating model view.
The key to their increasing popularity is because the Business Capabilities are expressed in terms of business outcomes and value rather than in purely functional or IT terms (i.e. Not just in terms of business unit needs or in terms of IT Solutions) thereby ensuring IT alignment with the business. Being expressed in terms of outcomes and values also means that Business Capabilities are tied to the outside in perspective of the Customer Journey and Strategic Scenarios, rather than the inside out perspective.
A good book to read about the outside in perspective is “Outside In: The power of putting Customers at the Center of Your business” by Harley Manning et al. http://www.amazon.co.uk/Outside-In-Putting-Customers-Business/dp/1477800085/ref=sr_1_1?ie=UTF8&qid=1371351364&sr=8-1&keywords=outside+in.
In order for an organisation to perform an activity, many parts of the organisation need to be involved. Consequently a Business Capability is modelled as grouping of other EA concepts including the following:
- Organisation Units
- Business Services
- Information & Data
- Application Services
- Infrastructure Services
In this way a Business Capability can be seen as a cross cutting slice through a typical enterprise architecture model.
A Business Capability is used for managing units of strategic business change and providing the mandate for programmes and project portfolio. Subsequently, project will develop a solution that either creates a whole new Business Capability or updates a Business capability by implementing a Capability Increment.
Thus, Business Capabilities and Capability increments provide the basis for the development of the EA Roadmap.
Business Capability Model
Figure 1: Example Business Capability Model Source: UK Government Reference Architecture (UKRA) v1.0
This diagram illustrates the start point for a Business Capability Model. This is a static view based on the style of IBM’s Component Business Model. This is a style diagram that has become quite popular.
The whole matrix represents all the Business Capabilities that the organisation performs. Each cell is a Business Capability.
The Columns usually reflect the high level value chain for the organisation or are major groupings of Business Capabilities that are meaningful to the business.
The Rows reflect the fundamental purpose of a Business Capability and there are normally three rows:
|Row||Aligned to the Viable System Model (VSM) system type|
|Direct (or Strategy)||System 5 and system 4|
|Control (or Management)||System 3, system 3* and system 2|
|Execute (or Operate)||System 1|
For details about VSM, the Viable system Model see http://en.wikipedia.org/wiki/Viable_System_Model and my earlier blog posts.
Business Capabilities also have dependencies between them. I.e. one Business Capability has to exist before another Business Capability can be achieved.
Implementing Business Strategies requires new or changed Business Capabilities, but for the most cases we are just changing some aspects of the Business Capability rather than introducing brand new ones. This is the Capability Increment.
Figure 2: Diagram showing Business Capabilities Source: TOGAF
The diagram above shows the relationships between Business Capabilities and Capability Increments, and also related the Enterprise Architecture development method phases and definition of work packages for the Programme and Project Portfolios.
Capability Increments document the changes to each Business Capability that are needed to implement the Business or IT Strategies.
Each Business Capability is decomposed into one or more Capability Increments that are typically implemented at different points in time and in different Transition Architectures. Each Capability Increment represents a unit of change.
Capability Increments also have dependencies between them. I.e. one Capability Increment has to be implemented before another Capability Increment can be achieved.
Figure 3: Capability Dependency Model
The diagram above shows the dependency relationships between the Business Capabilities and between the Capability Increments.
The Capability Increments can be rearranged to show the dependency order in which they need to be applied. This sequence forms the basis for the EA Roadmap.
Figure 4: EA Roadmap structure
Often it is may be useful (and politic) to represent several tracks in the EA Roadmap. For example tracks may be introduced for Strategic changes, Business changes and IT changes, since Capability increments may be identified in such a way that they can be implemented in parallel.
The Capability Increments can be grouped into Transition Architectures. A Transition Architecture is an intermediate Architecture model somewhere between the current state and the future (target) state Enterprise Architecture model being aimed for. A Transition Architecture will typically be aligned to intermediate and temporary stages in implementation.
Groups of one or more Capability Increments will provide the mandate for a solution or service to be developed in a project.
A Business Capability Model should be at the core of all Enterprise Architecture Models.
Often the Architecture Vision Model or Core Model is produced as a Business Capability Model to provide a strategic view that helps all stakeholders in an organisation to develop a common understanding of what needs to be done and what needs to be changed.
(With thanks to Lee Hepplewhite for some aspects of this approach)
11 November 2011
Enterprise Architecture is all about supporting strategic planning and business transformation activities, although many organisations seem to almost wilfully forget that this is one of the main purposes of Enterprise Architecture if not the most important one.
A business strategy is a long-term plan of changes for the whole enterprise which will address things like offering new products an business services, dealing with new customer or market segments, opening up niche opportunities, growth via mergers & acquisitions, cost consolidations and increased efficiencies. See http://en.wikipedia.org/wiki/Strategic_planning and http://en.wikipedia.org/wiki/Business_transformation
Enterprise Architecture primarily focuses on what an enterprise needs to do in order to stay viable, efficient and profitable in the future. In Viable System Model (VSM) terms, Enterprise Architecture is a System 4 type of system. See http://en.wikipedia.org/wiki/Viable_system_model
Enterprise Architecture bridges the gap between new strategy ideas and the execution of those ideas, in the same way that the intelligence corp in the military provide intelligence about current and future capabilities to the generals and ensure that the appropriate planning takes place in order to win the military campaigns.
Many organisations without an Enterprise Architecture function will risk failing to properly implement or deliver the on their business strategy.
It is frequently reported that many strategic ideas and initiatives identified by C-level executives are never properly implemented or seen through to full operation by the business units. That big picture of the business strategy on the white board in the CEO’s office or a high level presentation can look deceptively simple in a board meeting, but as they say ‘the devil is in the detail’. The C-level executives are responsible for seeing that the strategy is implemented, but it will be the Enterprise Architect that works out the detail.
Organisations need to know where they are now and create a baseline Enterprise Architecture model of their current state, then create a future target Enterprise Architecture model and do impact and gap analysis between them. The future state Enterprise Architecture model often needs to contain not just one single future target model but multiple complementary or competing models of the many future scenarios that are likely to have been developed using Scenario Planning techniques. See http://en.wikipedia.org/wiki/Scenario_planning
Strategic business transformation can be hard. Enterprise Architecture makes it far easier to answer questions such as:
- What Strategic initiatives are needed to fill the gaps found and address risks and issues?
- What new or changed business capabilities will be needed?
- What needs to be done when?
- How does one prioritise the different strategic business initiatives on an Enterprise Architecture roadmap?
- When are these investments in change going to be delivered?
- How will the initiatives be funded?
- What are the dependencies between the strategic initiatives?
- How will the business model be changed?
- How will the target Business Operating Model be changed?
- What organisation units and business functions need to be changed?
- What value chain and value streams need to be changed?
- What are the costs and potential revenues?
- How feasible is the business strategy?
- What feedback mechanisms between ‘systems’ will be needed?
- How will change be governed and how will compliance be assured? (i.e. how do we overcome resistance from difficult stakeholders, and the ‘Not invented here’ anti pattern?)
- What controls, KPI’s, CSF’s, incentives, bonus structures will be needed?
- What changes to the principles and standards will be needed?
- How do we align people, processes and technology?
- What other things have we forgotten?
I recommend reading the books:
- ‘Making Strategy Work: Leading Effective Execution and Change’ by Lawrence Hrebiniak and
- ‘Enterprise Architecture As Strategy: Creating a Foundation for Business Execution’ by Jeanne Ross and Peter Weill.
12 June 2011
Further to my last post, it occurred to me that another major difference between a Business Architect and a Business Analyst is that the Business Architect is a role on the demand side and the Business Analyst is on the supply side.
The Business Architect identifies the future demand for changes to the enterprise business model and associated business operating model and plans the change initiatives on the business part of the enterprise architecture roadmap.
The Business Analyst works in the here and now on how to satisfy the current business requirements for a single change project, where the project realises part of the supply schedule whereas the EA roadmap represents the future demand schedule of strategic changes.
The demand /supply distinction is clearer if the Business Analyst works in the IS/IT division since IS/IT often represents itself as a business (‘IT as a business’).
Interestingly the very concept of ‘running IT as a Business’ is counter productive and creates an unnatural barrier within an organisation. The IS/IT division is part of the business after all. Several commentators see this concept as a train wreck waiting to happen.
One could argue I suppose that if IS/IT is run as a business then the so called ‘Business’ will appreciate what IS/IT does for them.
But the problem with that (as seen in Chris Potts excellent story ‘FruITion’) is that IS/IT will not be invited to the top table where strategic decisions are made. See – http://www.amazon.co.uk/fruITion-Creating-Corporate-Information-Technology/dp/0977140032
I was recently asked what I thought was the difference between a Business Architect and a Business Analyst.
Broadly speaking I see the difference as being similar to the difference between an Enterprise Architect and a Solution Architect. i.e. one works at a Strategic level across the whole enterprise and the other works at a project level on a specific business domain or capability area in detail.
However the distinctions for Business Architects and Business Analysts are often far less clear.
This is because the terminology used by different organisations to describe a Business Analyst ‘s roles and responsibilities varies considerably from one organisation to another, and even fewer organisations have fully defined the role of a Business Architect.
Very often someone called a Business Analyst may in fact be working either as a Business Strategist, or as a Business Architect or as a Systems Analyst or as all three roles.
The following table illustrates the generic differences as I see them.
3 January 2011
When establishing (or indeed re-establishing) a brand new Enterprise Architecture function within an organisation there are perhaps two main approaches:
- A big bang approach
- A gradual iterative incremental approach
I favour the big bang approach. This is for several reasons:
1) a big bang send a clear and confident message to everyone in the organisation that things WILL be done differently
2) a big bang provides a clear mandate, mission, vision and positioning for the Enterprise Architects, sidetracking threats and challenges from others who feel threatened by the emergence of EA
3) a big bang ensures that the Enterprise Architecture function is given a solid budget and is established through a strategic change programme, complete with programme manager
4) a big bang has clear reporting to the CEO or appropriate C-level executive (since responsibilities vary from company to company) and clearly defined outcomes
5) a big bang needs clearly visible and continuous [sic] executive support
6) a big bang must have clear goals, objectives, measures, performance targets etc. Enterprise Architecture must be part of the business strategy to improve the organisation’s effectiveness and profitability.
7) a big bang ensures that proper effort is made choosing an appropriate EA framework, Meta Model, Process and EA tool
8) a big bang is JFDI on a large scale – get the whips and carrots out and get it done right first time ! Make it So !
Don’t get me wrong, iterative approaches do work well with established processes such as software development, but not for the introduction of new functions and processes that haven’t previously existed.
Establishing an EA function in small iterations is giving ammunition to challengers and doubters. There tends to be no mandate, no or limited budget, a quick and dirty mindset, limited access to experienced consultants, no EA tools, overall limited maturity.
It sends a message to the staff that the executive management is not sure, is not confident, and won’t invest in the success of Enterprise Architecture.
It’s a bit like changing governments, you don’t do that iteratively do you?
As Niccolo Machiavelli once said ‘Tardiness often robs us (of) opportunity, and the dispatch of our forces’.
30 December 2010
We are used to the idea of a Programme/Project Management Office (PMO) but often organisations fail to understand (or perhaps deliberately misunderstand) what the Enterprise Architecture function does. I propose that the Enterprise Architecture function is, in effect, an Office of the CEO, or an Office of the CEO and Strategic Change Management.
The book ‘Enterprise Architect as Strategy’ (http://www.architectureasstrategy.com/book/eas/ ) gives us the right way of thinking and talking about what enterprise architecture is for – creating a foundation for the execution of the Business Strategy.
This book is an essential read for senior executives, business leaders and enterprise architects.
Many people within an organisation will understand the big picture view of the business strategy, such as the CEO of course, but perhaps only at a shallow level of detail.
Would the C-level executives understand all the potential nuances and wrinkles that come with that business strategy? Perhaps not unless they were a ‘details’ person.
What does the CEO do? They will spend time in evaluating ideas, formulating the mission and vision of their orgnaisation, innovating the business model to ensure the company remains competive in their market, looks for future opportunities for expansion and carving out a niche market.
It is the Enterprise Architect who has the job of maintaining the big picture on the behalf of the CEO, in sufficient detail to ensure that it becomes a knowledge base to support the executive’s decision making and help them to realise the business strategy and govern the implementation of that strategy.
In this way the Enterprise Architecture function is effectively the Office of the CEO, providing strategic support to the CEO and the other C-level executives. It’s also worth stating here that effective companies focus on enterprise architecture and don’t jump straight into IT architecture. Enterprise Architecture is not the same discipline as IT Architecture.
We can look at the the Enterprise Architecture function in terms of Deming’s Plan-Act-Do-Check process improvement process:
The CEO and other C-level executives will stablish the mission, vision, goals, objectives, principles and metrics to identify the main outcomes of the business strategy.
The Enterprise Architect will help executives, business leaders and strategic planners to develop the business model, operating model, and other enterprise architecture models supporting business model innovation
The CEO and other C-level executives will evolve and innovate the Business Model.
The Enterprise Architect will take the business strategy and business model and support the development of the target operating model, communicate the business strategy, model the target and interim enterprise architecture models, plan an EA roadmap of strategic initiatives, identify and define the required capabilities, define the mandates for the investment programmes and key projects, define standards and process improvements. They will usually define the IT strategy to ensure that it fits with the business strategy rather than being developed in isolation (as unfortunately often happens).
The Enterprise Architect will perform EA governance, compliance and design assurance against those programes & projects implementing the strategic changes and new capabilities. They will perform gap analysis and impact analysis, measuring the performance and compare the results against the expected outcomes.
All the while the Enterprise Architect will report to the CEO and act as their trusted advisor. They will analyze the gaps, risks, costs, issues, assumptions and dynamics to determine their cause and determine where to apply further strategic changes in the next iteration of the cycle and improve the overall maturity level of the enterprise.
The mission of Enterprise Architecture is to improve the implementation and excecution of the business strategy, ensuring that the enterprise will survive, continue to develop and remain profitable in the future.
An interesting example to look at is the US Department of Health and Human Services which has established an Office of Enterprise Architecture as part of the Office of the CIO. http://www.hhs.gov/ocio/ea/index.html
As the the book ‘Enterprise Architect as Strategy’ says – ‘When it comes to executing your Business Strategy your Enterprise Architecture may matter more than your strategy itself… ’
23 December 2010
If you want to execute a business strategy then you’ll need an Enterprise Architecture function.
Enterprise architecture (EA) is about change – strategic change in an enterprise.
But not exogenous change – reactive change forced on the enterprise by outside exigencies – although that sort of change and those external forces may be taken into account. No, enterprise architecture is about endogenous change – directed, planned, strategy-driven change within the enterprise.
Enterprise architecture is about describing the desired future state of the enterprise and plotting a course towards that position in enterprise ‘state space’ known as the Target Architecture.
Recently there was a long and fruitful discussion on LinkedIn, between practitioners, of the proposition that “EA is not the glue between IT and “The Business”. EA is the glue between Strategy and Execution.”. Aside from the questions of whether “glue” is the right metaphor and the possible mereological fallacy of considering IT and “The Business” as separate entities in need of glueing, the proposition is also something of a false dichotomy.
The two aspects – Business-IT Alignment and Strategy Formulation-Strategy Execution are neither mutually exclusive nor independent from each other. So, as with many false dichotomies, the ‘correct’ answer is “both and neither”. But in terms of importance to the business or enterprise, being the glue between strategy formulation and its (presumably) successful execution is critical whereas getting IT aligned to the business needs is only a very useful and desirable outcome.
But the question this immediately raises is what exactly it means to be the glue between strategy formulation and strategy execution – which despite the lengthy discussion was not really answered.
How exactly does EA help strategies get executed – and executed well?
The standard ‘authorities’ [like “Enterprise Architecture as Strategy” by Ross, Weill and Robertson] actually don’t help all that much – offering general aphorisms like “First build your foundation for execution” and “Define your operating model”. Well, yes – but what does that mean and how does that get your strategy off the drawing board and put into effect?
In recent weeks I’ve been reading a somewhat ‘non-standard’ EA textbook, by a professor at Wharton Business School which addresses exactly this problem.
That book is “Making Strategy Work – Leading Effective Execution and Change” – and even though Dr. Hrebiniak never mentions the term, I would contend it is a book about Enterprise Architecture because it is about change, strategic change, in an enterprise.
Towards the end of chapter six he provides a very plausible answer to the question of how strategy execution is glued to strategy formulation in the form of a “Strategy Review Process – Planning, Execution, and Controls” [Figure 6.2]. See http://www.amazon.com/Making-Strategy-Work-Effective-Execution/dp/013146745X
In essence the process is an adaptive closed-loop feedback control (socio-technical) system that seeks to bring actual business performance towards that demanded by the ‘control’ input of strategic objectives through the following six steps:
1) Strategy Formulation – including resource capabilities and constraints, strategy and goals, industry forces and competitor analysis
2) Strategy Planning and Execution – including meeting the demands of strategy, [changing] organisational structure, Integration Requirements and Methods, Information Requirements, Hiring and Training People [Developing organisational skills and knowledge] and Appropriate Incentives
3) Review of Actual Business Performance – including emergent deviations from the planned strategy
4) Cause-Effect Analysis and Learning
5) Feedback / Change – including changes in strategy and changes in the capabilities of the organisation
6) Continuation and Follow-Through – including integration and review of strategy changes, resource (re)allocations and agreement on business performance objectives and measures
Where step 6 feeds back and leads back into step 1, closing the loop. Dr. Hrebiniak asserts “Every organisation must fashion its own strategy review process. It’s not a luxury but a necessity. It’s that important. …It supports execution”. I’m not sure how much the professor is hyping his own process – but if the strategy review process is the enterprise’s only formal link between formulation and execution, I‘d say there is little hyperbole – it really is that important. Execution is delivery, formulation is just structured aspiration.
So what has this to do with Enterprise Architecture?
Step 1 is strategy formulation – and it is the usual process of matching internal and external analyses of the enterprise for the future. Enterprise Architecture is *the* key contributor to the internal analysis – the resource capabilities and constraints are (should be) described by the EA model, the strategy and goals are the EA (model) Motivation Decomposition.
Step 2 is essentially the strategic planning of change – including people, processes and technology wrapped up as organisational ‘capabilities’, or business architecture, information architecture, functionality (or ‘applications’) architecture and technology architecture. Many would regard this as definitively Enterprise Architecture. Not only that, the changes are described by the Target and Current Enterprise Architectures (models) and a number of intermediate Transitional Architectures and the differences between them. The planning process is the EA gap analysis process.
This is EA as a strategic planning for change function for the enterprise.
In step 3 – the intended target or transitional enterprise architecture (model) provides the baseline against which actual achievement can be objectively measured.
In step 4 – well, correlation is not causation; it is actually remarkably difficult to determine the contributory causative factors to any particular outcome or effect. EA has a role in assessing how much of the (change in) business performance achieved is down to what changes in the enterprise.
This is EA as the basis for impact analysis of change. Did investing in that software development really cause the increase in sales of snow-shovels or was it that the weather was more inclement than most people anticipated this year?
Step 5 brings in capabilities again. EA should describe the relationship between the organisational capabilities and the resulting business performance. EA is there to help assess what returns investing in particular capabilities is likely to achieve – and therefore find the optimum investment pattern.
And step 6 is again into describing the architecture of the enterprise as it is now and how we want it to be – and how we are going to measure the progress towards the ‘to-be’.
From this perspective, Enterprise Architecture can be seen to suffuse the entire Strategy Review Process, making it systematic, rigorous and cohesive – like a resin glue.
So if you are the CEO of a company that does not have an Enterprise Architecture function or a Strategy Review Process, presumably you think all you need do is formulate and promulgate a strategy and the execution will take care of itself?
Me neither – I think you need some glue.
by Ian Glossop, Enterprise Architect.
8 December 2010
How does an Enterprise Architecture and a Business Model work together?
Successful organisations are those that improve and innovate their Business Models to find a profitable niche against their competitors.
But a new Business Model alone is not enough. It needs to be implemented and executed. This is where an Enterprise Architecture comes in.
If organisations do not align their Business Model and their Enterprise Architecture then how can they be certain of making it work?
The first step is integrating the Business Model with the Business Architecture part of the Enterprise Architecture. This is described below.
Business Model Canvas
Business Model innovation is rapidly becoming a hot topic and especially with the release of the book ‘Business Model Generation’ by Dr Alexander Oesterwalder. http://www.businessmodelgeneration.com/
This book introduces a standard way of developing a Business Model called the Business Model Canvas. If you are an Enterprise Architect highly recommend you read it.
Up to now most organisations had their own informal and idiosyncratic way of defining a business model that was unique just to themselves. This is the first time a standard for developing a business model has been defined and published.
The Business Model Canvas is a powerful approach for business model design and innovation.
It captures the 9 most essential elements of a business model in a simple way, enabling the design of a ‘business model on a page’.
The 9 different segments are
- Customer Segments
- Customer Relationships
- Value Proposition
- Key Activities
- Key Resources
- Key Partners
- Cost Structures
- Revenue Streams
You can see some example Business Models developed with the business Model Canvas at http://www.businessmodelalchemist.com/ and on an associate web site where you can view a variety of example Business Models and try creating your own can be found at http://bmdesigner.com/ .
So what does all this have to do with Enterprise Architecture?
Enterprise Architecture exists to provide a path between strategy and execution, identifying the current state and the desired future state and plot a roadmap of strategic changes between them.
See book ‘Enterprise Architecture as Strategy’ – http://www.architectureasstrategy.com/book/eas/
Enterprise Architecture provides the organising logic and architectural thinking needed to design the appropriate business capabilities need to implement a Business Model. To get the right outcomes, organisations must focus on Enterprise Architecture and Business Architecture not try and jump straight to IT architecture and solution design.
After setting the overall mission and enterprise vision, the first Enterprise Architecture domain that we need to model and align with the Business Model is the Business Architecture.
Business Architecture Model
A Business Architecture model is used further elaborates the 9 high level concepts segments that have been populated with conceptual themes and business strategies in the Business Model Canvas. A number of techniques and approaches, views and artifacts are used to explore the themes and strategies in each Business model canvas segment.
Create a Porter’s Five Forces model to explore the market and the general business environment in which the organisation exists. Also conduct a SWOT analysis.
Create a VPECT model to explore the Values, Policies, Events, Content (outcomes) and Trust relationships from the perspective of each different customer segment.
For details of VPECT read the book ‘Lost in Translaton’ by Nigel Green and Carl bate – http://www.lithandbook.com/
Create a Business Event model, further elaborating the Business Events identified with the VPECT model.
For each current and especially the future Events, create a Business Scenario. This should explore he what if questions that will effect the business model in the future.
Create a model of the various channels that exist between the organisation and its customer segments as well as between the organisation and its partners and suppliers.
Don’t forget those new social media channels, such as iPhone or Android phones and other devices and applications such as Twitter and Facebook. Partners can also be channels as well.
Create a model of the flow of business information between the organisation and its customers and between the organisation and its partners and suppliers (use the Actor Co-operation Viewpoint in Archimate).
Use VPECT to explore what Value you provide to each customer segment and what problems you solve for them.
Create a Value Proposition Model of the Products, Business Services and associated Values (using the Product Viewpoint in Archimate).
Value Propositions drive Business Strategy, so create a Business Motivation Model to understand all the relationships between Vision, Goals, Objectives, Strategies and Tactics associated with the Value Proposition.
See http://www.businessrulesgroup.org/second_paper/BRG-BMM.pdf for details of the Business Rules Group’s Business Motivation Model.
Key activities includes any model of behaviour,
This should include both internal Business (organisational) Services, Business Functions, Business Processes and Activities as well as the external behaviour of your customers, partners and suppliers.
In some cases it is useful to think about behaviour in terms of external services (the what) and the internal behaviour (the how).
Create a Business Function Model (using the Business Function Viewpoint in ArchiMate). A useful approach to use here is the Component Business Model approach from IBM. See http://www-935.ibm.com/services/uk/igs/html/cbm-bizmodel.html
IBM’s Component Business Model provides a good basis for visualising the Target Operating Model in terms of Business Functions or in terms of Business Capabilities (they’re not the same thing…).
Create a Business Process Model (using the Business Process Viewpoint in ArchiMate). Business Process Models are not just Process Hierarchy Models but include Value Chains and Value Streams.
Create Value Stream models for each Event/Outcome pair (use the Business Process Viewpoint in Archimate) identified in the customer relationship segment above.
Create a Value Chain model at a high level for each customer segment (also using the Business Process Viewpoint in Archimate).
See http://www.opengroup.org/archimate/doc/ts_archimate/ for details of modelling the Business Architecture Layer in Archimate.
As they are high level abstract views, Value Chains are often specified more in terms of Business Functions than the more specific Business processes or Activities.
Resources in this segment can be further elaborated by the other Enterprise Architecture domains or Information Architecture, Application Architecture (and Application Service Architecture) and Infrastructure Architecture.
However before jumping to the IT Architecture it is better to start more conceptually and create an Enterprise Vision Model and a Business Capability model.
Enterprise Vision models are those high level one page models described as ‘core’ models in the book ‘Enterprise Architecture as Strategy’ (http://www.architectureasstrategy.com/book/eas/) and also in TOGAF Phase A.
You can also use the Layered Viewpoint in ArchiMate to produce Enterprise Vision Models.
Create a Business Capability model. This is usually a hierarchy model similar to a Business Function Model but remember that a Business Function and a Business Capability are two different concepts.
A Business Function is a high level view of existing internal behaviour from an organisational perspective, where the business functions are closely associated with the organisation units.
A Business Capability is defined by TOGAF9 as ‘A business-focused outcome that is delivered by the completion of one or more work packages’. A Business Capability is defined as the ability to execute a specified course of action, to achieve specific strategic goals and objectives. A Capability is defined in terms of the outcome of the course of action, one that has a business value. The concept of Capability is used in the military context and the MODAF framework where it is described in the abstract. See http://en.wikipedia.org/wiki/Capability_management and http://tinyurl.com/2vge39e
See also my previous post on Modelling Behaviour.
Create an Organisation model (using the Organisation Viewpoint in ArchiMate) to capture the human resources and their roles and responsibilities.
Create a Business Information Model (using the Information Structure Viewpoint in ArchiMate) to understand the knowledge, information and data resources within the organisation. Outcomes identified as Content in the VPECT model and in the Value Stream models are also modelled here as Business Information (represented by Business Object, Meaning and Representation object types in ArchiMate).
Identify your key partners, suppliers as carefully as you do your customer segments and customer relationships.
Don’t forget that Enterprise Architecture includes the extended environment as well as the organisation itself. This extended environment includes the Suppliers and Partners (use the Actor Co-operation Viewpoint in Archimate).
Explore the costs with a Total Cost of Ownership (TCO) model. This can be a spreadsheet.
Create a System Dynamics Models to fully explore and understand the cause and effect relationships between different stocks and flows, and run simulations.
Also explore revenues with a TCO model as with the Cost Structures
Remember that revenue doesn’t always mean profits in terms of money, but can be other non-monetary outcomes of value, (especially relevant for Government departments, non-profit and charity organisations who seek outcomes in terms of benefits to citizens and indirectly, votes).
It is again very useful to produce System Dynamics Models to understand the cause and effect relationships between different stocks and flows.
I think it’s surprising that more organisations don’t use System Dynamics as part of their enterprise architecture modelling. More on that subject in a future post…
Other Enterprise Architecture models
Starting from the Business Model Canvas, the Business Architecture views described above are used to further elaborate the details of the business model and to understand what needs to be realised from a business perspective.
After that the Business Architecture model is aligned to the Information/Data Architecture model, the Application Architecture model and finally the Infrastructure Architecture model pretty much as usual. I mostly develop these models using Archimate combined with other concepts from TOGAF 9 as needed, using tool such as Avolution Abacus and BiZZdesign Architect.
Note that other variations of Oesterwalder’s Business Model Canvas are starting to emerge. This is a sure sign that the concept is an important one that is reaching a tipping point.
These other business model approaches include:
14 October 2010
- BiZZdesign Architect
- Avolution Abacus
- Sparxsystems Enterprise Architect
- IDS Scheer Aris,
- System Architect
- Salamander MOOD
5 September 2010
Organisations need a new paradigm. In order to survive, old dogs are going to have to learn new tricks. They need to start fundamentally thinking about how to change the way in which they innovate, think and make decisions. To allow future operations to be more efficient, c-level executives and senior managers will need more accurate and real time information for better decision making and to optimise business strategy execution.
At a strategic level they need to leverage existing expertise and technology to deliver the capabilities they desire. Organisations will need to provide their decision makers with access to enterprise knowledge, allowing them to gain the insights that will enable the best alignment of operational performance with business strategy and objectives.
For effective knowledge management and information sharing they will not only need Enterprise Architecture, but will need Smart Enterprise Architecture.
The vision of Smart Enterprise Architecture is an approach that will enable information to be captured in real time, analyzed and proactively used to enhance business performance through predictive risk-based decision-making.
Sign up to Download the Diagram
See also IBM on predictive Analysis at http://tinyurl.com/39sdn3p
In the past, the technologies used in organisations have been relatively simple, now organisations will need to become ‘smart’.
What can make Enterprise Architecture smart is not new technology in itself, but rather innovative ways of combining existing state-of-the-art measurement and feedback mechanisms that can respond to changing conditions and allow an organisation to be agile and adaptable.
This vision is similar to that of Stafford Beer in his Viable System Model which he first described back in 1972. A Viable System is any system organised in such a way as to meet the demands of surviving in a changing environment, primarily by being adaptable. See http://en.wikipedia.org/wiki/Viable_System_Model
If he was still around today Stafford Beer would probably have been an enterprise architect.
To make Enterprise Architecture smart we have to gain value from examining the approach to process optimisation in other industries, such as the car industry.
In the not too distant past when a car was serviced, the diagnostics and fine-tuning of its systems were performed manually, with simple tools, skills & experience and heavy lifting. By contrast, the modern car engine is simply plugged into a computer diagnostic system which interfaces with the car’s onboard computers. The computer is linked to dozens of digital sensors that instantly monitor all the car’s systems and informs the mechanic what adjustments are needed. The car’s computer continuously controls its engine management system in real time as you drive along, optimally adjusting the engine parameters to adapt to the driving conditions and your driving style to maximise economy and minimise emissions.
So for Smart Enterprise Architecture we need the same kind of continuous state-of-the-art measurement and feedback value stream to control and adapt the organisation in real time. The following diagram illustrates the use of Enterprise Architecture in a continuous value stream or ‘value loop’.
See paper http://tinyurl.com/2em3k3m and also Deming’s Plan, Do, Check & Act cycle and Six Sigma’s Define, Measure, Analyze, Improve & Control cycle.
Once the Enterprise Architecture models are established it will be possible to make them the centre of predictive analysis, enabling the generation of strategic options in response to the real time changing behaviour of the enterprise.
Those strategic options can be kept in compliance with the business strategy, goals and objectives to continuously provide the best way to optimise value.
Organisations will need to look outside themselves and their traditional partners to find new skill sets and capabilities in order to develop a Smart Enterprise Architecture.
Join the Enterprise Architect community
This post is also available at http://tinyurl.com/29qunfd
28 August 2010
There are still organisations that have not yet established an Enterprise Architecture function.
A simplistic and immature view of the Enterprise Architecture function is that it is only used to create a target architecture model for the IS/IT architectures that enable the IS/IT Strategies, create IS/IT roadmaps, and generally act as a Technical Design Authority for solution development projects.
But is this all that the Enterprise Architecture function is used for?
For the C-level executives in an organisation there just is not enough detail available to answer their questions, so they often appear to look for simple and quick answers to difficult and complex problems. This is not usually good decision making.
Business users frequently think of their business strategy in terms of decisions about technical solutions.
Are business users best placed to make these technical decisions?
They need to think about what their needs are how and think in terms of what business capabilities they need before rushing to ‘solutioning’.
There is a need for thinking and decision frameworks to help c-level executives and business leaders make their decisions.
What then, is a thinking and decision framework?
Decisions are made at every level across an organisation about:
- New Investments or business as usual changes
- Formal or Informal changes
- Tactical or Strategic changes
- Secret or well known changes
- Business or IS/IT changes
But does anyone actually know all the decisions that are being made in an organisation?
Questions are often asked within organisations at all levels:
- What decisions are IS/IT making?
- What decisions Business are making?
- Who should make decisions anyway?
- What decisions have been made?
- What if I don’t like the decision?
- Are the decisions still valid?
- Do I need to comply with the decision anyway?
Is the right decision being made – How would we know?
Are decisions being made without thinking, evaluation, pilot studies, use of facts etc?
Frequently this appears to be the case!
What makes better decision making?
- Business intelligence
- System thinking / System Dynamics
- Management models such as Porter’s Five Forces
- Thinking frameworks such as VPEC-T
What about using Enterprise Architecture helping to improve decision making?
Do you remember the mantra of ‘IT Enabled Business Change’ often used by government departments?
Shouldn’t this now be a new mantra of ‘EA Enabled Strategic Change’?
Remember, ‘When technology leads, it’s not enterprise architecture’!
Enterprise Architects are strategic assets, organisations should use them as such, at a corporate level, to support better decision making and for creating a solid foundation for the execution of the business strategies?
Existing policy making or decision making processes need to be adapted to make use of the Enterprise Architecture function, and most business change should be viewed as EA-enabled strategic change.
We are used to the idea that Enterprise Architecture function establishes an EA Governance process, an Enterprise Architecture Review Board and an EA Compliance process to guide the activities and deliverables of solution architects.
With the introduction of an Enterprise Architecture function there needs to be changes in the decision making roles and responsibilities at all levels.
The top business managers and executives will still make the strategic decisions for the enterprise and guide and plan the business structuring, but will now make decisions with a different level of abstraction and in a different way supported by the Enterprise Architecture function.
The Enterprise Architecture function will help with business decisions such as:
- Business strategy decisions on transformations, mergers/acquisitions etc.
- Business model decisions on customer segments, new products and business services
- Target operating model decisions on business capabilities
- Strategic changes and initiatives.
The Enterprise Architecture function can directly make independent decisions about:
- IS/IT Strategy (supporting the CIO)
- Target Enterprise Architecture model and Enterprise building blocks
The Enterprise Architecture function also supports and guides IS decisions about Solution building blocks, IT decisions about Technology and Operational decisions about Infrastructure upgrades etc.
As well as developing and maintaining the Enterprise Architecture models, the Enterprise Architecture function can keep track of the RACI for decisions, and maintain a decision log (typically owned by the Enterprise Architecture Review Board) and publish these on the Enterprise Architecture web site and other deliverables.
As Plato said, ‘A good decision is based on knowledge not [just] numbers’, and the Enterprise Architecture provides just that knowledge base.
This changes the way business strategy and strategic change are approached and increases their benefits.
As Jay Forrester said in his paper, Designing the Future, “Organizations built by committee and intuition perform no better than would an airplane built by the same methods… As in a bad airplane design, which no pilot can fly successfully, such badly designed corporations lie beyond the capability of real-life managers.”
Organisations without a real strategic Enterprise Architecture function are just like those ‘organisations build by committee and intuition’.
EnterpriseArchitects.com helps those involved in strategic change to truly understand the issues and concerns and become more successful in building a better ‘enterprise’.
Join the Enterprise Architect community
This post is also available at http://tinyurl.com/253zsth
28 August 2010
Organisations always have an implicit architecture, but not always an explicit architecture.
If they do have an explicit architecture, the chances are that it is an IT Architecture that has evolved over the course of hundreds of little decisions made by developers and project managers over the years.
Perhaps these decisions have been made by the CIO in consultation with the IT department and the business who ultimately have to pay for them.
The question is this IT Architecture the right architecture for the organisation?
Many of the business leaders certainly don’t think that they have the architecture they need or deserve.
Increasingly I hear business leaders talk of IT as part of the problem and not part of the solution.
The move to outsourcing and cloud computing is a knee jerk reaction by the business to bypass that slow, constraining old IT department they don’t like and think is too expensive.
The IT Architecture then represents what has happened in the past.
In many cases it’s not quite the fault of the IT department.
They’ve tried their hardest over the years and have done away with business and systems analysis in favour of Agile (the new quick and dirty) approaches in blinkered projects.
This has meant that many IT systems and processes have ended up as string and sealing wax solutions, each in their own silo, as one bank told me last year.
It’s easier for the business to hack together an end user computing (EUC) solution (i.e. Access or a Spreadsheet) or buy a cloud based solution outside the control of IT.
These are unstructured and dangerous, but within limits have given the business the control and responsiveness they wanted.
However ultimately these non-IT solutions hinder an organisations ability to execute its latest business strategy.
So the concept of Architecture is brought back to sort out the mess. But the IT Architecture has not had the impact at the right levels to have the right effect and be the right architecture, so we need something else.
To get the right architecture, organisations should focus on ‘real’ enterprise architecture, not IT architecture, and certainly not IT Architecture just renamed as Enterprise IT Architecture.
Top performing organisations use Enterprise Architecture, with it’s business and strategy driven approach, to help them mould their business strategies, identify the goals and objectives, guide the development of their Business Models and Business Operating Models, establishing the new set of Business Capabilities they require, provide advice and help shape the strategic initiatives that are plotted on an enterprise architecture roadmap in order to drive the execution of their strategies.
The outcome of Enterprise Architecture doesn’t necessarily involve IS or IT changes, it all about the business needs.
Smart organisations have found that using ‘real’ Enterprise Architecture, instead of just a focus on IT Architecture, has helped the business plan and manage mergers & acquisitions, major e-Business transformations & consolidations, grab hold of new business opportunities and introduce new offerings faster better and cheaper.
EnterpriseArchitects.com can help your organisation use ‘real’ enterprise architecture to achieve greatness.
This post is also available at http://hub.am/c4uN
8 July 2010
I recommend you read Chris Curran’s excellent blog entry on 16 Enterprise Architecture Strategies Learned The Hard Way
I’ve included his list below with my views and comments following that.
1. An exhaustive enterprise level blueprint is virtually impossible to build – it’s too big and no one will buy-in
2. The best strategy blends a direction-setting enterprise blueprint and business unit and domain blueprints
3. Centralized accountability for the EA function is a predictor of success
4. A centralized team of architects is critical in driving EA standards and approaches
5. Architects must be assigned to projects as core team members (60%+ of total EA FTEs) rather than “advisors”
6. EA should be measured in 2 ways: business capabilities delivered and costs of core services
7. Measure EA as an asset – what does it cost to provide the service and what return does the business get from the business capabilities delivered?
8. Architecture leadership requires strong management, business operations and technology skills, most likely in 3 different types of people; don’t expect your chief architect to run the EA function
9. Methods and governance must be integrated into existing work processes (eg, project approvals, SDLC) rather than a new overlay
10. Enterprise Architecture is not always the best name for communicating; maybe Strategy & Planning or Enterprise Transformation is better
11. The best large companies have “business architecture” teams reporting to the business (or dual reporting to business and IT)
12. Leading companies have reference architectures in place for 90% of the technical domains
13. Your senior enterprise architects must have the right cultural skills and awareness to integrate well with upstream business partners and downstream technical users
14. High performance groups maintain consistent, formalized EA involvement in the SDLC to translate blueprints into sufficiently detailed starting architectures for each project as well as accurate cost and resource estimates
15. Mature organizations target 40% EA resource time for strategic planning and 60% on SDLC tasks, and typically err on spending more time on SDLC tasks
16. Strong credibility and trust amongst Business and IT partners is a predictor of EA success. Credibility has typically been gained via joint strategic planning efforts, one project at a time.
These are my comments on Chris’s list.
1. The enterprise architecture blueprint (i.e. the enterprise architecture content) needs to be developed in iterations, and treated as a living document/model that will never be complete. Aim for each iteration to provide value in it’s own right, to both the business and the rest of the organisation.
2. I agree that there needs to be different aspects to the business and IS strategies that address different segments of the enterprise. They shouldn’t conflict with each other though. Enterprise Architecture is all about aligning the IS strategy to the Business strategy and target business [operating] model.
3. The EA function needs an executive sponsor such as the COO that is accountable for the success of EA. I’m increasingly of the opinion that the EA function should not report to a CIO that is only focused on IT. This sends out the wrong message to the organisation as a whole. The COO should be focused on the success of the business and how it operates as a whole and not just the success of IT. In some cases success for the business may mean less IT as business capabilities in the cloud are used instead of local IT capabilities.
I’ve seen some suggestions that a new C-level post is needed to manage Strategic Change and Enterprise Architecture , that of a Chief Strategic Officer (CSO). This new role makes sense if the COO is only responsible for service delivery operations & support activities.
4. I agree – A centralized team of enterprise architects is critical in driving EA standards and approaches. There is also room for federated EA teams in large global organisations where centralised control is not feasible or even possible with local regional and country based regulatory environments.
5. Its the Solution Architects that should be assigned to projects as core team members. Enterprise Architects will be involved from a governance, compliance and design assurance perspective in quality gates/steering group meetings, and as an advisor. There are usually not that many enterprise architects and too many projects for them to be core members of every project.
Being a ‘Core’ member of a project team implies that they are managed by the project manager, whereas the relationship should be the other way around – the project manager needs to heed the advise and direction coming from the enterprise architects who have a governance sign off at the end of each project phase in project steering group meetings.
6. I agree that EA should be measured in terms of business capabilities delivered, but also in terms of value delivered. Cost of services is just one of many ways of measuring value. The value of EA is indirect though and value is only realised by solutions that deliver the business capabilities in the future many months away. To measure EA properly though means that there need to be a good record of decisions that are made by EA and the eventual outcome of these decisions in the future. This doesn’t happen much in my experience at the moment.
7. EA is a core business function in the same way that Finance Management or Sales & Marketing are core business functions. We should treat the Enterprise Architecture content as a knowledge management asset. The value is the return on knowledge (ROK) that is used in supporting decision making.
8. The EA function does need strong leadership. Doesn’t always get it though. In all the EA teams I have encountered, the Chief Enterprise Architect does also run the EA function. Within a larger EA team, there are often specific managers for the Business Architecture, Information Architecture, Application Architecture, Infrastructure Architecture aspects.
9. I partially agree. Aspects of EA Governance, Compliance and Design Assurance processes should be integrated into existing Strategic Planning, Portfolio Management, Programme and Project Management, Software Development and Service Delivery processes, but the Enterprise Architecture Development process (i.e. TOGAF ADM) will be a new overlay.
10. The name ‘Enterprise Architecture’ is all too easily confused with ‘Solution Architecture’, ‘IT Architecture’ which is a source of confusion so there are often suggestions for new names for ‘real’ Enterprise Architecture. I’ve not yet found a new name I like though it is becoming common to include Enterprise Architecture within a Strategic Change Management team.
11. Business Architecture is just one of the domains of Enterprise Architecture. All of Enterprise Architecture should be reporting to the business (i.e. the COO) rather than to IT (i.e. the CIO).
12. A Reference Architecture is a key component of the target Enterprise Architecture as a whole. In some cases these are provided by industry reference architectures.
13. I agree in general although I’d say that Enterprise Architects probably need to be much more business focused than IT focused. IT is often seen as part of the ‘problem’ and EA needs to be in alignment with the business.
14. This is more the responsibility of the Solution Architects who need to liaise with the Enterprise Architects to translate the Enterprise Building blocks into Solution Building Blocks. The Solution Architects should ideally form part of a ‘virtual’ EA team.
15. The 40% EA resource time on strategic planning and 60% on SDLC tasks mainly reflects the current overemphasis on IT Architecture being done by Enterprise Architects. I think the ideal percentages should be the other way around i.e. 60% strategic planning and 40% project related work.
16. I agree that the credibility of the Enterprise Architects and their trust relationships is critical. Building that credibility and trust starts with working closely with the business on strategic change programmes
27 June 2010
I was thinking about System Thinking and how very few organisations that I have worked with have made use of this approach and associated System Thing tool such as iThink.
The same applies to Enterprise Architecture modelling and associated EA tools.
There is often a cry from some people that the resulting models are too complex.
‘Can’t I simplify it ‘ they cry. ‘It’s too difficult to understand’.
In one case the diagram in question was a relatively straightforward Application Architecture diagram showing 180+ Applications and a simplified view of the interfaces between them. At the time it made me smile since I’d previously worked with an Application Landscape that contained over 3000 applications!
However there is a real problem here of a general resistance to the use of Enterprise Architecture modelling (and also of the use of system thinking) revealing the underlying complexity of systems, and a wider problem of aversion to getting to grips with complexity.
Many people I think are afraid of complexity in general and are afraid of any model that reveals the underlying complexity. These people would like the world to be simple and straightforward (perhaps due to their limited education?).
It’s important to understand that the world is not at all simple, and simplistic solutions will not be sufficient for all problems.
The application of the right modelling tools, expertise and approaches will need to vary depending on the type of problem that needs to be solved.
The Cynefin model is useful for helping people understanding that different approaches are needed for different classes of problem.
The Cynefin framework defines five context spaces: Simple, Complicated, Complex, Chaotic and Disorder.
For problems that fall into the Simple context space, the relationship between cause and effect is obvious to all, and the approach is to Sense – Categorise – Respond and we can apply best practice.
For problems that fall into the Complicated context space, the relationship between cause and effect requires analysis & investigation with good models and/or the application of expert knowledge, and the approach is to Sense – Analyze – Respond and we can apply good practice.
For problems that fall into the Complex context space, the relationship between cause and effect can not be instantly perceived without testing and simulation, including using System Thinking / System Dynamics modelling and simulation approaches. The approach to use is to Probe – Sense – Respond and look for emergent meaning.
For problems in the Chaotic context space, there is no obvious or intuitive relationship between cause and effect at systems level, the approach is usually known as JFDI (Just Effing Do It) and consists of trying something out and seeing what the hell happens – an Act – Sense – Respond approach.
The Disorder context space is the state of not knowing what the problem is in the first place and doing nothing and hoping for the best.
Unfortunately ‘Hope is not a Strategy’.
Complex models can only be made as simple as possible but no simpler. Ultimately you’ll have to live with complexity.
Knowing when to use the right modelling tool to manage complexity is the best strategy.
Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses handle it.
2 June 2010
There has been much discussion about the ten Enterprise Architecture pitfalls that Gartner published at http://www.gartner.com/it/page.jsp?id=1159617
In the meantime, Jane Austen and Seth Grahame-Smith have also published a great book: Pride, and Prejudice and Zombies: The Classic Regency Romance-now with Ultraviolent Zombie Mayhem!
In a spark (fit?) of imagination, the title of this blog was raised up from the depths of Mordor and just wouldn’t die…
This is a light hearted, tongue firmly in cheek, look at Gartners 10 EA pitfalls written as a story just ripe for gore and senseless violence…
A world where Enterprise Architecture exists in an alternative universe where Zombies roam the corporate landscape. The denizens of this doomed land are the “stricken”, the “sorry stricken”, the “undead”, the “unmentionables”, or just simply “zombies”. The Zombies are those in an organisation who wittingly or unwittingly subvert the best intentions of those valiant enterprise architects envangelising about the benefits of Enterprise Architecture.
The Gartner 10 EA pitfalls are an excellent set of EA anti-patterns and avoiding them will result in a better Enterprise Architecture function within an organisation.
If you can’t avoid these pitfalls then it’ll seem as if you’re suddenly transported into the world of Zombies.
1. The Wrong Lead Architect: This is a classic and common anti pattern where the Chief Enterprise Architect turns out to be a zombie (an ineffective leader). He or she may not really understand Enterprise Architecture at all but has been put into the role by senior management because they were the only one available (dead man’s shoes?). This Dark Lord “He-Who-Must-Not-Be-Named” (ok, his name is Lord Voldemort) is making decisions with a forked tongue, for seemingly no reason whatsoever, other than to spy out opportunities and jobs for other zombies perhaps. Devoid of real interest in Enterprise Architecture he actively campaigns against its introduction.
Best thing to do is chop their head off, but as Harry Potter knows, this is easier said than done. Expect an uphill battle.
2. Insufficient Stakeholder Understanding and Support: This happens when the hordes of living dead outside the Enterprise Architecture team ignore what the EA team is doing, continually questioning the value of anything not related to their immediate problems, usually project related. This is because they are undead vampires who do not live in the real world. Get sharpening those stakes and hang up the garlic to keep them away. A huge problem occurs when the Enterprise Architecture team loses its executive sponsor. As with the volcano, Eyjafjallajökull, ash clouds of Fear Uncertainty and Doubt will start filling the air. Who is going to pay attention to the Enterprise Architects when they don’t have a sponsor?
Best thing to do is get a new sponsor as soon as possible, or start dusting off your old CV.
3. Not Engaging the Business People: Zombies don’t understand the living. They only talk to other zombies and don’t communicate much anyway. They think that Enterprise Architects are just another species of Solution Architect or Technical Architect. To overcome this make sure you get involved with the business and with real business decision making. This is not easy if the business are used to making decisions without the support and involvement of the Enterprise Architects (I’ll cover decision making in a future blog). Communications with the business units are frequently lost when the messengers are captured. Zombies that don’t like the enterprise architecture message will kill and eat the messenger. Yum.
Best thing to do is create a great communication plan and be clear about the messages, be sure to engage with the living at all times to create value and ROI and to placate the Zombies.
4. Doing Only Technical Domain-Level Architecture: Some people think that an Enterprise Architect is just another name for a Solution Architect who deals with applications used at the corporate level by all business units. These people look alive but are really undead.
Best thing to do is to clearly distinguish between the roles and responsibilities of Technical focused Solution Architects and business strategy focused Enterprise Architects. Wearing a garlic necklace should also help…
5. Doing Current-State EA First: Successful Enterprise Architecture is about the future, about strategy and governance. Zombies live in the present and worry about the current state and short term gains and don’t care about the business strategy and why they are there. They do lots of howling. Enterprise Architects are there to help the business make money in the future, faster, better cheaper.
Best thing to do is to focus on the future target business model and how to realise it.
6. The EA Group Does Most of the Architecting: The Zombies are not informed by those alive on the business side. There is consequently no buy-in for developing the Enterprise Architecture content. Zombies just want to kill people and make more zombies. They are dead anyway so don’t care about the future. The primary job of real enterprise architects is to wear silver crosses, kill zombies, vampires and werewolves.
Best thing to do is to lead the Enterprise Architecture process to develop the future architecture rather than live in an ivory tower and impose their favourite ideas.
7. Not Measuring and Not Communicating the Impact: The value of real EA is often indirect, so it won’t be obvious to the Zombies in the organisation. This then exposes the Enterprise Architecture function to the risk of failure and being beheaded. If you don’t measure what EA does then how can you manage it?
Best thing to do is to build an EA scorecard, plan the EA roadmap, concentrate on continually providing and communicating the value of EA to the living, kill zombies, sharpen your axe, and grow garlic.
8. Architecting the ‘Boxes’ Only: Enabling better business agility is frequently a key EA goal, but Zombies only care for their projects or business unit and generally won’t be rewarded for providing corporate benefits. Enterprise Architects work for the whole organisation. Where is the one true ring to help to defeat a rampaging horde of Zombies and fight the ever-present threat of a Zombie apocalypse?
One (EA) Ring to rule them all, One (EA) Ring to find them,
One (EA) Ring to bring them all and in the darkness bind them..?
Best thing to do is focus more on business strategy and the business capabilities that cut cross the business silos to provide value, polish your stakes and silver crosses and look for the one true ring.
9. Not Establishing Effective EA Governance Early: Zombies live without any governance. The quick and dirty rule, and regard the living Enterprise Architects as a troublesome, albeit deadly, nuisances. Enterprise Architects must resist the temptation to wait for more enterprise architecture content before establishing credible Enterprise Architecture governance and compliance processes.
Best thing to do is develop EA content and EA governance in parallel and constantly cry “I have a cunning plan”…
10. Not Spending Enough Time on Communications: Zombies will ignore Enterprise Architects unless they are hungry for blood. Key messages about Enterprise Architecture will not be intuitively obvious to Zombies, if at all. Enterprise architects must constantly work to educate the living business and kill all zombies.
Best thing to do is keep sharpening the EA axe and evangelise with tailored messages to your audience.
With apologies to Harry Potter, Lord of the Rings, Black Adder and the book – ‘Pride and Prejudice with Zombies’ (http://tinyurl.com/al6gvx ) which originally inspired this blog entry…
This blog bears absolutely no relation to any organisation either living, dead or undead. Comments and Lawsuits to Harry.Potter@Azkaban.org.uk
24 May 2010
Jeanne W. Ross recently proposed the following.
“Let me propose the following hypothesis: Although EA was initially a function within the IT organization, we will soon find IT to be a function within EA. This is actually not a wild theory; it’s a trend.”
- Jeanne W. Ross, Foreword, The SIM Guide to Enterprise Architecture, CRC Press, 2010, p. xli.
This is a great proposal.
Making the IS/IT function part of the Enterprise Architecture (EA) function makes much more sense than having the Enterprise Architecture function as part of IT.
Unfortunately the latter situation is far too common as organisations make the mistake that EA is somehow a more specialised version of Solution Architecture and Technical Architecture.
From the business perspective, the IS and IT functions are often seen as part of the problem and if the Enterprise Architecture (EA) function reports to IS/IT then by association it can also seen as part of the problem.
Since EA is very close to the business by definition (i.e. the ‘Enterprise’) this make life for an Enterprise Architect very difficult. Their natural and main business stakeholders will be wary of sharing their discussions on strategy and business ideas with EA.
The EA function should ideally report to the executive board and be a peer with the business functions.
Often the EA function reports to the CIO. If the CIO is the head of IS and IT functions, then this can be a problem.
Ideally the Chief Enterprise Architect (i.e. the CEA) should be a new ‘C’ level executive position and a peer of the CIO and not report to the CIO.
This would instantly give the Enterprise Architecture function the level of authority and position with the organisation hierarchy that it needs to do its job properly.
See also the discussion on this topics started by Birgitt Hartje
Recently I’ve tried the latest versions of the following EA tools:
- BiZZdesign Architect
- Avolution Abacus
- Salamander MOOD
- MetaStorm ProVision
The first two are definitely modern tools that fully support IEEE 1471 concepts and separation of concerns. Easy to use and good for Enterprise Architecture modelling without fuss.
Both are excellent. MOOD is fine and attractive, but I’ve used it less in anger.
The last two suffer from an odd design quirk that means that a view (i.e. a diagram) must belong to an object.
The result of this quirk is that to create context free diagrams they must belong to a dummy object. Why are these tools built this way ?
Another common feature is a proprietary way of drawing business process flow (Workflow / Event value chain) diagrams in a truly BPMN style.
The data object that is input or output from a Business Process or an Activity is not the same data object that is modelled elsewhere in the tool. Mega is particularly bad at this.
Neither Mega or ProVision seem to know how Services (Business Services, Application Services etc.) should be modelled either.
A colleague also pointed out to me that many EA tools are pretty limited when it comes to modelling the Infrastructure Architecture at an Enterprise Architecture level. Both Mega and ProVision are the most limited in this domain.
Both Mega and ProVision can be customised to improve them for EA use, but I for one would expect support for modelling SOA and the infrastructure to be there by default. I’d also expect to see support for the de facto EA modelling language ArchiMate to be there by default.
In comparison both Avolution Abacus and BiZZdesign Architect are sweet and painless to use and do everything you want them to do.
So why are they not in Gartner’s Magic Quadrant for EA tools then?
27 January 2010
Being an Enterprise Architect is a role I enjoy but I recognise the scenario described by Rik Laurens at http://www.capgemini.com/technology-blog/2010/01/enterprise_architecture_the_on.php
I think the main underlying issue is that the Enterprise Architect doesn’t, in any organisation I have engaged with, actually ever command a budget.
With money comes the power to spend it and influence others who will come to rely on that money being spent in their direction on their project etc.
Without the money weapon, an enterprise architect must rely on their powers of influence and persuasion with the C-level executives, and their governance sign off power at end of project phases and giving approval at project board meetings.
As the enterprise architecture discipline has not yet reached the tipping point where the majority of organisations realise its key importance and give respect to the Enterprise Architect, this influence and persuasion is still often overruled by JFDI thinking when the going gets tough.
Enterprise Architects do always have to continually demonstrate value and ROI, even if it is indirectly achieved by the delivery projects months away when they implement what you have defined in the EA roadmap.
However I think that Enterprise Architects do need to closely align themselves with the C-level decision makers (CIO, Business management etc.) in an organisation rather than with the project teams to achieve the necessary power and influence.
I know this sounds a bit Machiavellian, but if you are aligned too much with delivery then you’ll be seen as a [project level] solution architect and not as an [strategic] enterprise architect which is where you want to be in the first place.
It’s a fine line to walk.
Before all else, be armed [with a budget].
26 January 2010
I thought that the Forrester blog on the Archetypes of EA is an interesting read. You can see this at:
In particular the chart of Strategy/ Project versus Business / Technology is a useful one for understanding the difference between Enterprise Architects and Solution Architects.
The quadrants on the right hand side of the chart relate to the more strategic focus of an Enterprise Architect and those on the left hand side focus on the project/delivery focus of Solution Architects.
The top right quadrant is where the enterprise architect is performing the Business Architecture part of the EA role. This would involve governance work as well.
The bottom right is where the enterprise architect is supporting the IT Strategy, defining the current state and the future target state of the enterprise architecture and EA roadmaps between them.
The top left quadrant is the focus of each of the Solution Architects and the bottom left quadrant is the focus of the Infrastructure Architect.
It is interesting to also compare the quadrants above with the activities identified in this chart below (also from the Forrester Blog).
21% of the time would be spent in the top left quadrant on application delivery projects.
15% of the time on the bottom left quadrant spent on infrastructure.
16% of the time on the bottom right quadrant on developing strategic plans.
By my estimate an Enterprise Architect therefore spends almost half their time (40% – 49%) in the top right quadrant working on Business Strategy alignment.
1 September 2009
In the recent post at http://tinyurl.com/mg9k7h
‘ Is it Enterprise Architecture or IT Architecture?’, the author asks whether Enterprise Architecture should be renamed?
I see this argument from the other way around.
I would say that there has always been a difference between Enterprise Architecture and technical architecture.
The former has its origins in the Zachman Framework which has always included the business architecture aspects.
Technical architecture has evolved to become IT architecture and IT planning.
Most organisations have kept business architecture and IT architecture separate because of the typical separation of responsibilities within an organisation.
They like to keep IT in there place so to speak.
The language of IT architecture has claimed that it now deals with ‘enterprise’ level software, i.e. software applications like SAP that are used across all the business areas. For this reason many IT architecture efforts now rather erroneously call themselves Enterprise IT Architecture (EITA) or Enterprise Architecture, whereas in fact they still only address IT architecture subject matter.
So when people claim to have been doing EA this is likely not to have been actually true and the ‘inclusion of Business Architecture as one of the domains of EA’ is somehow a further misrepresentation.
EA has always been a method for ‘architecting the enterprise’, it’s just that IT Architecture is trying to claim EA’s clothes.
The move from TOGAF 7 to TOGAF 8 and now TOGAF 9 illustrates this path.
Many organisation’s have yet to truly understand that EA is different from EITA.
As someone who has been trained in the Zachman Framework and IFW since 1995 and done ‘real’ EA, it is clear that IT Architecture should no longer try to claim to be Enterprise Architecture, but concentrate instead on being Solution Architecture and clearly distinguish itself from Enterprise Architecture which really doesn’t need to change it’s name.
A sheep in wolf’s clothing is still a sheep.
31 August 2009
A conversation recently reminded me of an issue I have frequently seen before.
Organisations that have not had an Enterprise Architecture function have funded all changes in projects that are funded by the business areas.
The result is that the first project that needs new infrastructure or new application services that will be shared across the whole enterprise are obliged to seek funding for it on their own. Subsequent business sponsored projects can then reuse this new infrastructure or shared enterprise service without funding any part of it.
However is also not uncommon to find that the new projects in the other business areas don’t actually realise that there is anything that can be reused and can get quite a long way down the road developing their own new applicattions, services or infrastructure that duplicate the functionality before realising they could have reused an existing capability. In some organisations I have seen, the outcome is a large amount of duplicated functionality and therefore additional costs.
With an Enterprise Architecture function in place the EA governance process should prevent projects duplicating functionality, but the funding remains based on the business areas budgets.
What is needed for infrastructure chages and application services and applications that will be used by multiple solutions from mutliple business areas is enterprise level funding. With this funding model, a business area would fund the business specific parts of the solution that a project is delivering and the cross business area functionality would be funded from an enterprise level budget, sponsored by the enterprise architecture review board. Some projects will be initiated that are purely sponsored by the enterprise and not by any of the business areas.
This funding model seems an obvious approach to have in an organisation with an enterprise architecture function in place, but so far I have never encountered it.
20 May 2009
What does agile mean?
Mostly the interpretation is that it means doing the work in an iterative and incremental fashion, so that each new iteration can be flexible enough to rapidly react to constant change.
This is a good approach that should be taken regardless of whether one is doing enterprise architecture or solution development.
Other interpretations is that agile means development without architecture or analysis, where the design only meets the current set of known requirements and the solution being developed must be refactored when the requirements change.
This is good for development but not so good for long term strategic planning of enterprise architecture.
Terry Blevins has made some important insights in at the Briefings Direct blog
Enterprise Architecture exists to support the decisions that are made every day in an organisation.
Enterprise Architecture helps to really understand the decisions that need to be made and to ensure that the decisions are made based on the facts.
Each iteration of the enterprise architecture processes needs to be aligned to the speed at which an organisation needs to make decisions.
In this way enterprise architecture be made agile. At the enterprise level, it’s not about agile development but agile decision making.
8 May 2009
Are the rapid Agile development approaches compatible with the longer term strategic planning approach of Enterprise Architecture?
Maybe ‘agile’ is just a very overloaded word and we should instead talk about Iterative and Incremental Enterprise Architecture?
One of the main concerns I have always had is that the concept of ‘Agile’ is closely associated with ‘Quick and Dirty’ in the minds of many clients who are happy to trade off quality for rapid development. The concept of Agile and of Enterprise Architecture do seem at first glance to be incompatible – you wouldn’t really want to develop a quick and dirty enterprise architecture especially where the impact is strategic, long term and very costly. It doesn’t matter if you have to refactor a solution a few times to get it right for the current set of user stories, but refactoring the whole organisation is less feasible.
I am fully behind the idea of an iterative and incremental approach to both developing an Enterprise Architecture (as described in TOGAF9 and FSAM) as well as for solution development (with RUP, FDD, Perspective, DSDM etc), but don’t want to encourage low quality outcomes that can result with pure agile approaches like XP.
I always found the original XP process to be rather anti-Analysis and anti-Architecture but I believe that both Analysis and Architecture are very necessary in the appropriate context and scale.
For developing a Solution I often used to advocate having two parallel processes that might be called Agile Analysis and Agile Development with the Agile Analysis process feeding requirements/user stories into the Agile Development process.
I’ve started this as a discussion on the LinkedIn group on Agile Enterprise Architecture.
The new ArchiMate 1.0 specification can now be seen at http://www.opengroup.org/archimate/doc/ts_archimate/
See the Open Group press release at http://www.opengroup.org/press/21apr09.htm
This is the tipping point…
5 June 2008
I have been reading Andy Winskill’s blog on his suggested Elevator pitch for Enterprise Architecture – ‘Enterprise Architecture is about the identification and realisation of Competitive Advantage‘.
I think this is an excellent pitch that has the benefit of being concise and focused on the business language of senior executives.
My own elevator pitch is ‘Enterprise Architecture is the bridge between strategy and execution‘.
To expand on this pitch, I usually point people towards the excellent ‘Enterprise Architecture as Strategy‘ book by Jeanne W Ross et al.
I also sometimes describe EA as a realisation of the System 4 (focusing on strategy/future/intelligence) in Stafford Beer’s Viable System Model. Or as a combination of System 4 and System 3 (focusing on audit/control/governance). This doesn’t work so well as an elevator pitch unfortunately as most people are not familiar with Stafford Beer’s work and will just give you a blank pitying look…