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.
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)
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:
The form may be downloaded from here:
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.
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… ’
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
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.
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].
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.
Today I returned to the Sparx Systems web site to see what was new and was pleased to discover that the Enterprise Architect tool can now be extended with a new MDG technology add on for the TOGAF 8 Architecture Development Method, in addition to the previous add on that was available for the Zachman Framework.
The Enterprise Architect tool is already a great tool and this add on is sure to be popular. TOGAF is increasingly mentioned as a desirable skill in job specifications for Enterprise Architects.
Of course, now that the Open Group has adopted the Archimate Enterprise Architecture modelling language standard, the next add on I’d like to see is one for Archimate.