An agile EA technique.
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 began to find that this was not good enough. One issue was that my external and internal customers wanted more areas to be covered in much less time. Another was that events were regularly overtaking me both from business and technology aspects, and I was unable to stay in control of the plans.
I had to do something. Being a believer in the time-honoured EA method, I predictably first tried to stuff more of it within the same time. 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 instead from gut feeling and 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 turned out okay, but enough initiatives were either not taken up or had sub-par results that I was forced to deprecate this approach too.
I returned to the method drawing board around 2017 and came up with 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 can be taken by an Agile Enterprise Architect.
[Please note that the technology and business transformations may themselves take some time. 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. Do not try to perfect the associated picture. That can happen within the program. The 20/80 per cent rule applies: Launch with the 20% decisions that provide 80% of the business value.
- Go right to the top decision-makers. Sell the roadmap to those who will override any naysayers and doubters at lower levels. Identify the âBig-3â (usually the triumvirate of the business area head, the technology head and the 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 real revenues and costs savings. Technologies keep changing. They will come and go. Do not put tons of time on 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 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
Do this with the business domain heads. (I am a great believer in DDD â Domain Driven Design. Iâll tell you more about it some time.)
A. Capability Hot Spots
Identify what is missing in terms of 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 that are dragging on the enterprise and where they are coming from â people, software, hardware or partners. 2 days.
D. Unagile DevOps Hot Spots
Find capabilities that need to change often and fast but are struggling to do so. ½ 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 are – banking, airline, pharma, telecom, 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 are – marketing, sales, customer service, supply chain, 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 after that. 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 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 have not 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 lengthy. If you want to see instances of them, you are welcome to drop me a request at Quality-Thinking.com Q&A.
The Open Group has drafted an Agile Enterprise Architecture Framework 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 to use the technique in this article if you are an EA, or share 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 news modes of thinking and working. Otherwise neither they nor we will be doing our best.
Connect with me: 
