Enterprise Architecture Lifecycle
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.
Context
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.
COBIT
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.
| COBIT5 reference | Process |
| 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 |
RACI
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.
Enterprise Architecture Survey
16 June 2013
A friend of mine Ian Glossop, is doing a survey of views on Enterprise Architecture, and as many of you are Enterprise Architects he would appreciate your views on the subject.
I know your time is precious, and the survey is a little long, but nevertheless may I urge you to take a little time to complete it.
The survey is implemented as a PDF form, with the ability to save the data you enter and so may be completed and emailed back to:
Ian Glossop ( ian.glossop@glomal.co.uk) at your convenience.
The form may be downloaded from here:
http://www.glomal.co.uk/EASurvey/EASurvey.pdf
Ian is doing this as part of an MSc course in Technology Management with the Open University, so he would very much appreciate your help.
The thesis that Ian is testing is twofold really:
- That there is a common core to the diversity of EA methods/methodologies and
- That it is a new-ish (if you can call 25 years old ‘new’) integrative discipline.
If you would like a copy of the results, simply let Ian know and he’ll send you something in September or October.
Thanks.
Business Architecture
23 March 2013
Tom Graves recently participated in an Open Group TweetJam on Business Architecture. You can read about the results of this at http://weblog.tetradian.com/2013/03/20/opengroup-on-bizarch/
Unfortunately I didn’t hear about this in time to participate but I thought I’d record my own thoughts here.
The questions were:
- How do you define Business Architecture?
- What is the role of the business architect? What real world business problems does Business Architecture solve?
- How is the role of the business architect changing? What are the drivers of this change?
- How does Business Architecture differ from Enterprise Architecture?
- How can business architects and enterprise architects work together?
- What’s in store for Business Architecture in the future?
How do you define Business Architecture?
Business Architecture is one of the primary domains within Enterprise Architecture. It deals with the architecture of the business, ideally from a business perspective and is expressed in business terminology.
It should not really be considered a separate discipline from Enterprise Architecture but often is by those who persist in misunderstanding that Enterprise Architecture is only about IT and not about the whole of the enterprise.
Business Architecture deals with the structure and design of how an enterprise operates, makes money or delivers value, how it organises itself in order to provide products and business services to its customers, clients and consumers. It should be expressed independently of how the business architecture will be mapped to the underlying application architecture and infrastructure architecture, but is more connected to the business/contextual view of the information/data architecture and will include the organisation architecture.
Business Architecture is centred on the business and the business strategy, not on IT or on the IT Strategy and should not be considered just a source of requirements for IT projects (which is the impression that TOGAF gives of Business Architecture).
In general Business Architecture includes the following deliverables:
A Business Architect is primarily concerned with supporting and advising the senior executives, providing advice and guidance, and influencing decision making for the Business Architecture domain.
What is the role of the business architect?
As a specialised type of Enterprise Architect, they are in a leadership role, close to business management working for the CxOs to evaluate and elaborate possible future strategic scenarios.
They have a responsibility to guide, recommend and oversee the realisation of the business strategies identified by the CxOs, but they don’t control the business strategy or make the actual investment and strategic change decisions.
What real world business problems does Business Architecture solve?
As a type of Enterprise Architect, a Business Architect deals with strategic change, business transformation activities concerning topics such as:
- Ecommerce changes
- Consolidation
- Cost reduction
- Process improvement and efficiency
- New organisation design
- Mergers & Acquisitions
- Reuse of shared services
- New markets
- Regulatory and legal changes
One should not forget that, by definition, an Enterprise Architecture model covers everything about the enterprise including the environment and market which it operates in, its Business Strategies, its Business Architecture as well as the rest of the Enterprise Architect domains.
How is the role of the business architect changing? What are the drivers of this change?
The role of a Business Architect is becoming much more distinct than it has been. many organisations are maturing their enterprise architecture functions that were previously just centred on IT architecture and are now specifically introducing a Business Architect role.
How the Business Architect role differs from other roles such as a Business Analyst, Business Change manager, Business Transformation Manager etc. is still playing out. I discussed this to some extent in a previous blog post – The difference between a Business Architect and a Business Analyst.
Another current difference is that a Business Architect is often closely associated with the Business units (and perhaps reports to a business line manager of sorts) and therefore is seen as being on the ‘Demand’ side of a business, whereas the rest of the Enterprise Architects (including IT Architects) are often lumped into the IT department and therefore are seen as being on the ‘Supply’ side. In theory, the Enterprise Architects, including Business Architects, should only ever be on the ‘Demand’side and not seen as part of IT. They should report to the CxOs, ideally seen as part of a CEO Office.
How does Business Architecture differ from Enterprise Architecture?
A Business Architect is a type of (a ‘real’) Enterprise Architect. Business Architecture is a sub domain of Enterprise Architecture.
How can business architects and enterprise architects work together?
Of course they can. The distinction in the question is artificial anyway, since a Business Architect is just a type of Enterprise Architect that specialises in the Business Architecture domain.
But in reality many organisations do have an unfortunate tendency to make up their own interpretation of what these roles actually are.
What’s in store for Business Architecture in the future?
We will see more and more Business Architecture roles in the future as organisations mature their enterprise architecture strategy and capabilities, and they realise that they need to get to grips with their business model and how it is realised. They will need Business Architects to help them do that.
For most enterprises embarking on large scale strategic planning and business transformation programmes it is all about staying robust, viable and efficient, continuing to deliver good outcomes and value to their customers/consumers/clients in the future. Enterprises should be wanting to stay competitive and efficient and beat the competition.
If the enterprise is to succeed, it must make strategic decisions and investments in change based on a thorough architectural gap analysis/impact analysis that is only possible with business architecture as a key part of their enterprise architecture function.
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.
on Enterprise Architecture 
