Agile Enterprise Architecture Strategy & Planning
Architecture Essays
There are three reasons an organisation adopts Enterprise Architecture or makes the best use of it for transformations:
- Expansion — When an organisation needs to scale up significantly, Enterprise Architecture ensures it will happen smoothly, quickly, and cost-effectively.
- Diversification — A company may diversify its products or services organically or by acquiring or merging with others. Enterprise Architecture is vital for doing this successfully.
- IT Delivery & Operations Quality— Organisations often have disorderly and inefficient IT solution delivery and operational services. Enterprise Architecture brings order, quality, and speed.
In the early 2010s, I used to take about three months to deliver an IT transformation roadmap for one business area of an enterprise. Towards the middle of the decade, I found this needed to be improved. One issue was that my external and internal customers wanted more areas to be covered in less time. Another was that events regularly overtook me from business and technology aspects, and I could not control the plans.
I had to do something. Believing in the time-honoured EA method, I predictably tried to stuff more of it in the same period. But an EA depends on information and inputs from a spectrum of people, and all this approach did was stress me out with no apparent increase in output. So, reluctantly, I tried cutting steps from the sequence. I reduced the technology comparisons to recommend from experience and gut feeling, dropped the creation of anything resembling a proper business case, and demanded blind trust in the value of the change. The results were patchy. Some transitions turned out okay, but too many did not take off or had sub-par results, and I had to deprecate this approach too.
I returned to the method drawing board around 2017 and found better answers. The resulting technique has proved capacious, fast and sound based on the evidence from applying it over ten EA initiatives.
Today we will look at this quick way to provide architecture and technology directions to boost our customer's business. It is a set of uncomplicated and practical steps that an Agile Enterprise Architect can take.
[Please note that the technology and business transformations will take the time they need. We are not dealing here with quickening them. That is another matter altogether.]
The keys that made the difference were:
- Identify and plan the big gun transformations. Refrain from trying to finalise and perfect their details. That can happen within the program. The 20/80 per cent rule applies: Launch the 20% transitions that provide 80% of the business value.
- Go right to the top decision-makers. Sell the roadmap to those who override naysayers and doubters at lower levels. Identify the 'Big-3' (usually the triumvirate of the business area head, technology head and finance head). Do not waste time convincing all the stakeholders.
- Get the architecture right, and do not get hung up on the technology. The right architecture provides actual revenues and cost savings. Technologies keep changing. They will come and go. Do not put tons of time into getting the technology perfect.
- Go Open and Go Services Assembly. More open-source, open standards, open infrastructure. More services assembly than product integration. Save a ton of selection time with these two approaches. And even for these, use analyst reports to narrow it down rather than vendor/supplier deep dives. If others have spent the time, don't repeat it!
The picture below shows the method. Please study it.
Firstly, note the time bounds for every cycle or sprint — 30 working days! You don't have to use all 30 days just because I have put that in the picture. But anything less than 20 days for an EA roadmap cycle would be suspect too.
Secondly, note the pulsating nature of finding the necessary changes and then paring them down: Many business hot spots -> Trim to Top 3 Needs -> Top 9 reference architecture gaps -> Trim to Top 3 Programs -> Top 9 area-architecture gaps -> Trim to Top 5 Projects.
The Steps
1. Find Business Hot Spots
(Examples of Business Reference Architectures – BIAN for banking, eTOM for Telecom, IATA models for Airlines, et al.)
Do this with the business domain heads. (I am a great believer in DDD — Domain Driven Design. I'll tell you more about it sometime.)
A. Capability Hot Spots
Identify what is missing regarding market/customer or internal business operations capabilities. These can also be called Functional Hot Spots. 1 day.
B. Quality Hot Spots
Locate shortfalls in the quality of existing functions. Important ones would be — capacity/performance, reliability, scalability and security. 1 day.
C. Cost Hot Spots
Recognise high-expense functions dragging on the enterprise and where they come from — people, software, hardware or partners. 2 days.
D. Unagile DevOps Hot Spots
Find capabilities that need to change often and fast, but it isn't proving easy. ½ day.
E. Prioritised List
Work out the Top-3 Needs in A-D above with the help of the customer stakeholders. Make sure that the Big-3 decision-makers agree and own the lists. ½ day (stop clock till client reverts).
2. Map Hot Spots to Industry Technology Reference Architecture
(Examples of Industry Technology Reference Architectures – MIRA-B for banking, FrameWorx for Telecom, Open Group CARA for airlines, et al.)
A. Reference Architecture Gaps
This is all you. Only for the Top-3 Needs, map and identify the Top-3 Gaps in capability and quality each in the reference architecture components, with help from an Industry Architect, to get 9 gaps. 1 day.
B. Impact Assessment
For the resulting 9 gaps above, make the top Architecture and Technology Decisions: cover function placement, data sourcing and integrations. List the software, hardware, product, service and process changes required. Give it to an estimator to work out the ballpark cost of all of it. 3 days.
C. Prioritised Transformations
With the help of the Client Business Heads, prioritise the above 9 gaps into the Top-3 Programs. 1 day.
3. Map Hot Spots to IT Area Reference Architectures
(Examples of Technology Area Reference Architectures – California DoT for EAI, NIST for security, ODA for digital engagement, IBM/AWS/Azure for cloud, et al.)
A. Area Reference Architecture Gaps & Roadmaps
This is all you again. Only for the Top-3 Programs above, map and identify the Top-3 Gaps and Maturity Roadmaps in capability and quality in the applicable area reference architecture components, with help from an IT Area Architect. 3 days.
B. Impact Assessment
For the resulting 9 gaps above, make the top Architecture and Technology Decisions: cover function placement, data sourcing and integrations. List the software, hardware, product, service and process changes required. Give it to an estimator to work out the ballpark cost of all of it. 4 days.
C. Prioritised Projects
With the help of senior Project Managers and the client Technology head, prioritise the above 9 gaps into the Top-5 Projects. 3 days.
4. Define Programs & Projects
A. Program & Project Business Cases
Only for the above Top-5 Projects, get a senior Business Analyst and work out the RoI time frame and the gains. Get the Big-3 aligned on this. It is a must, else, do not proceed. 3 Days.
B. Prioritised Investment Plans
Propose a tentative investment plan to the Big-3 for the Top-5 Projects. However, they need to define and own it, not you, the EA. 2 days (stop the EA clock till the client decides).
C. Program & Project Definitions
Define the programs, constituent projects, dependencies and timelines at a high level (only). Work with senior project managers. 3 days.
5. Govern Execution
A. Principles, Guidelines and Policies
As the EA, provide these for the delivery teams so that they stay on the optimum technology and architecture path. Refine in subsequent cycles. 1 day.
B. Solution Quality-control Gating
Gain Big-3 championing for time-bound solution quality check go/no-go gates at Requirements, HLD, UAT and Operations.
C. Learning Recycling
There will always be learning for everyone. Capture it for everyone and fertilise the next cycle. 2 days.
…
A good friend of mine always reminds me to give examples. So, I have put the method picture and the following three example diagrams into the Slideshare below.
- Example Industry Business Architecture Model with Hot Spots Annotation
- Example Industry Technology Reference Architecture
- Example IT Area Reference Architecture
I haven't put examples of the roadmaps for technology and architecture nor the governance frameworks and processes, as you can guess what they look like. Also, they would make this article too long. If you want to see instances of them, please drop me a request at Quality-Thinking.com Q & A.
The Open Group has drafted an Agile Enterprise Architecture Framewo,rk which you can read here: https://publications.opengroup.org/s192. If you can apply it, please do so. But it may take you some time to understand and use it. Meanwhile, I encourage you to use the technique in this article if you are an EA or discuss it with your EA.
The activities of the world are going faster and faster. We architects, especially enterprise architects, need to match the need for speed of our clients by adopting new modes of thinking and working. Otherwise, neither they nor we will be doing our best.
[Glossary: IT — Information Technology; EA — Enterprise Architecture; BIAN — Banking Industry Architecture Network, eTOM — enhanced Telecom Operations Matrix; IATA — International Air Transport Association; MIRA-B — Microsoft Industry Reference Architecture-Banking; CARA — Commercial Aviation Reference Architecture; DoT — Department of Technology, EAI — Enterprise Application Integration; NIST — National Institute of Standards and Technology; ODA — Open Digital Architecture; HLD — High-Level Design; UAT — User Acceptance Testing]
Originally published at https://www.linkedin.com.