Agile Enterprise Architecture
Part 3 of the Agile Architecture Series
Making it to number 35 in the Top 100 superpower list is being able to predict the future (“Precognition” ign.com). Besides the obvious personal gains, it could be pretty valuable for product design and architecture work.
Wouldn’t it be great if, when we are making arbitrary design solutions while building out our brand-new product, we could predict the future and know which design will be the best in 5 years?
What if our software was truly agile, and we could tweak it to take advantage of market changes and user demand.
How about maximising our engineering capacity without too much backtracking and waste?
Enterprise Architecture
In the first two parts of the Agile Architecture Series, I’ve been focusing more on Solution Architecture. Solution Architecture is about developing the “best” design/architecture for a particular problem or project.
One of the things missing, however, is a guiding light that sits outside the project and helps us choose the right pathway or solution for the overall product and organisation. … something that has a longer-term view and is aligned with the big goals (or Big Rocks) that the organisation aspires to.
Solution Architecture vs Enterprise Architecture
If you are lucky to have a title (or role) of just “Architect”, how do you know if you are doing Solution Architecture or Enterprise Architecture? I use this simple rule.
- Solution Architecture is what your boss asks you to work on. Usually they are the important and/or urgent projects.
- Enterprise Architecture is what you need to work out for yourself which is critical for the business’s long-term success.
Can Enterprise Architecture Predict the Future?
Sure! In a way ... maybe.
Enterprise Architecture can help predict the future by enabling organisations to build in an agile way. By creating flexible frameworks and architectures that adapt to changes, businesses can anticipate and respond to emerging trends and challenges more effectively.
Enterprise Architecture promotes a structured approach to understanding an organisation’s current state, defining its desired future state, and charting a path. Through this process, organisations can identify potential risks, opportunities, and market shifts, allowing them to proactively adjust their strategies and operations.
What are the Steps to Developing an Enterprise Architecture (that can predict the future)?
- Identify the important stuff or Big Rocks.
- Know your Current State & Status.
- Map out your Future State.
- Govern your Future State.
These things are familiar in the world of Architecture and Strategy. We sometimes forget about developing and using our Enterprise Architecture when we are neck-deep in Agile sprints.
Having Current State and Future State roadmap artefacts produced from an Enterprise Architecture practice can help us with context and meaning when planning our agile delivery.
The Important Stuff — The Big Rocks
There will always be Urgent and Important work to do.
“If everything is important, then nothing is.” ― Patrick Lencioni
If you are surrounded by lots of urgent and vital work, these things are not your Big Rocks. You will need to look harder.
- What is the company’s Vision / Strategy / Goals?
- Who are your stakeholders? Who are the leaders with the long-term vision?
- It’s effortless to identify (and get distracted by) the low-hanging fruit. Let someone else take the lead on those things. Keep your focus on the Big Rocks.
Know your Current State & Status
After you work out your Big Rocks, you must understand what you have and how it works. In the words of the great TV personality —
“You can’t change what you don’t acknowledge.” — Dr. Phil McGraw
Capabilities, not Processes or Systems.
When building out your current state, it’s easy to list all the systems and connect them together. But it doesn’t always tell you what you need to know.
If I was to have something like Salesforce in my current state. What is that telling me? Is that the Customer Master? Is it the customer service platform? Is it the Sales platform…
- Lead with your capability (E.g. Customer Management, Product Servicing, Payments, etc.).
- Map the system to the capability.
- Make an assessment of the capability. What are the issues?
Fast-tracking this part
In general, generating a current state architecture takes time and effort. But there are some things that you can do to fast-track the process.
- Usually, a new Enterprise Architecture initiative can be built on the remains of a previous Enterprise Architecture attempt. If you dig hard enough, you might find some valuable artefacts.
- Does the organisation have a CMDB? (Configuration Management Database). A good CMDB will have all your systems, descriptions and business and technology contacts.
- Use an industry framework to give you a head start. Personally, I like BIAN (bian.org). It has a great capability model for banks and financial institutions. Using a framework like BIAN will help you understand what capabilities you are missing, capability areas that are underdeveloped, and capability areas that are duplicated.
Map out your Future State
“Without a clear destination in mind, every decision becomes arbitrary” — Unknown.
What does a Roadmap look like?
Part 1 — The Basics
These are the essential ingredients that come out of an Enterprise Architecture practice.
- Principles. Just a few principles aligned with the company’s values are enough. Principles are the “does it make sense” test when evaluating solutions.
- Standards. Standards help build consistency in your technology stack.
- Patterns. Help you to be more agile and consistent.
Part 2 — The Specifics — Capability and Portfolio Roadmaps
Now that you have your current state worked out and have understood the issues and challenges around it, visualise what it will look like in a few years.
- Capability Journeys. Express the change needed for Automation Targets, addressing Operational Risk, Scalability, etc. Work out what is essential to improve a capability to meet the “Big Rocks”.
- Portfolio Roadmaps. Now that we understand the capabilities that need to be uplifted to meet our Big Rocks, have a good look at the Product portfolios and start to think in terms of “Invest”, “Retire”, and “Transform”.
Create some Marketecture.
Marketecture = A non-technical document to explain your architecture to anyone.
Now that you have worked out what you currently have and your target state, summarise it on a one-pager. Carry the one-pager around with you and show it to everyone.
Your Marketecture will show —
- Your current systems and capabilities
- Systems and capabilities that you are investing in.
- Systems that have issues or are on the way out (perhaps colour-coded)
It might be more than one page, but not more than four. (I used to do an origami fold that showed a few different views on a single A3).
Govern your Future State
In Part 2 of the Agile Architecture Series, I talk about “Trust but Verify”.
We want our Agile teams to run fast and build awesome stuff. We also don’t like them making arbitrary design decisions that don’t consider the organisation’s long-term “Big Rock” goals.
The Answer is (can be) simple.
- Ensure everyone knows the roadmaps, where we want our Capabilities and Product Portfolios to be in a few years.
- Put some light governance in place to ensure that architecture and designs are reviewed before implementation.
Summary
So, while Enterprise Architecture may not offer a crystal-clear view of the future, its emphasis on agility and adaptability empowers organizations to make informed decisions and navigate future challenges with greater confidence and resilience.
So —
- Know Your Big Rocks — What is truly important.
- Understand your current state and status. (Think in terms of Capabilities)
- Map out your Future State
- Govern your Future State
In the next and final part of the Agile Architecture series, I will address the issue of what we do with legacy and the need for Architecture refactoring.
