I have spent the past few months thinking about why I would want to implement a complex and detailed enterprise architecture framework. I’ve always been an agile thinker. How can I rapidly implement a digital transformation using an enterprise architecture framework? Thus, I did some research and thinking. Below are my summarized thoughts. I include references and sources.
Good enterprise architecture takes a lot of work. The process, roles, and responsibilities are well-defined. There is a benefit to following a model that others use. But does the benefit outweigh the cost?
“The fundamental quality of Enterprise Architecture is its vision of the future.”
– Angelo Andreetto in Is Enterprise Architecture Completely Broken?
The TOGAF framework emphasizes vision definition as early as possible. However, fully defining the vision and creating an implementation plan can take a substantial effort. The actual implementation of the vision could be many months into the future. This approach provides little agility for businesses that are driving fast and deep transformations.
“Our architecture was changing faster than you can draw it. As a result, it wasn’t useful to try to draw it.”
– Adrian Cockcroft in Agile Enterprise Architecture Finally Crosses the Chasm
I can’t recommend using an enterprise architecture framework that essentially follows a waterfall approach while development teams are using Agile and DevOps. The two cannot coexist without creating tension. Only one can emerge victorious – or perhaps neither; but the organization may fail in achieving the vision in the end.
In 2010, the IBM Software Group reported on why enterprise architecture (EA) programs were cancelled. I am listing the top ten reasons below. EA failure was deemed to be due to “overpromising and under-delivering” or to “people issues”. These failures are very concerning to me. The success factors / strategies reported that “people issues” was the primary driver of success.
- Insufficient time provided
- Project teams didn’t take advantage of the EA
- Too difficult to measure benefits
- Enterprise architects perceived as “ivory tower”
- Development teams couldn’t wait for enterprise architects
- No perceived benefit of EA program
- No executive endorsement
- Enterprise architects weren’t sufficiently flexible
- Enterprise architects perceived as impediment to success
- Insufficient funding
The IBM Software Group report made the following recommendations.
You need to understand the business
- Architecture must be based on requirements, otherwise you are hacking
- There are two aspects to architecture, business and technical
Individuals and interactions
- Supplying models and documents isn’t sufficient
- Support project teams
- Roll up your sleeves and work closely with the teams
- Architecture comes from teams, not individuals
I found this report to be quite enlightening. The report recommended more communication and interaction. There should be less focus on models and documents with more focus on solutions that work immediately. For example, reduce the technical risk on a project by proving the architecture with code. This is a recommendation that the TOGAF framework does not seem to support. But you must do this in an agile environment. I often tell people that the benefit of a good diagram is that it explains an idea or concept to many different people. They all can have a common understanding and then continue to work. The value of the diagram is not to create it as part of a framework; the value is in the benefit it provides to others.
Furthermore, the goal is not to create many diagrams. This just means more maintenance work over time. Diagrams can be thrown out when they no longer serve their intended purpose. Thus, another goal is to “travel light” as work moves forward. Use a slim model that can be quickly updated or replaced as needed. It seems to me that the report is recommending moving to a much more agile approach to enterprise architecture.
Scott W. Ambler provided the following principles for capturing enterprise architecture in an agile manner:
- Organizations are complex systems
- Complex systems cannot be managed at a fine-grained level, but only at a meta level (management by rules)
- Documentation for complex systems should be coarse (high level)
- Describe how things work in principle
- Predictions should be fuzzy and described as ranged probabilities
- It is more important to strengthen a system’s resiliency than it is to document
- Accept some disorder and ambiguity
- Working examples are more valuable than documents
I think that these principles support agile development. This is probably the right time to mention the Manifesto for Agile Software Development.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Thus, in my opinion, the enterprise architecture framework must support successful agile software development. It should not be the reverse situation. That is, agile software development must not support successful enterprise architecture implementation. In the latter case, both would fail because they cannot coexist in harmony.
An agile enterprise architecture framework that supports agile software development would benefit an organization. This would allow an organization to rapidly implement digital transformations in response to market pressures.
Marc Lankhorst lists two new enterprise architecture frameworks that provide a more agile approach: Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD). He provides a comparison of TOGAF’s Implementation Governance (Phase G in the ADM) with SAFe. Marc states that “agile methods strongly rely on feedback loops, whereas TOGAF’s governance is rather feed-forward in nature”.
I think that I need to read more of Marc’s blogs and other resources. I want a better understanding of what an agile enterprise architect must do to support the enterprise organization and the agile software development teams. At least, I want validation that my current understanding is on the right path.
|https://www.slideshare.net/ScottWAmbler/agile-enterprise-architecture-62467855||Agile enterprise architecture||Scott W. Ambler||May 27, 2016|
|https://www.forbes.com/sites/jasonbloomberg/2014/07/23/agile-enterprise-architecture-finally-crosses-the-chasm/#65e4035852a5||Is Enterprise Architecture Completely Broken?||Jason Bloomberg||July 11, 2014|
|https://www.forbes.com/sites/jasonbloomberg/2014/07/23/agile-enterprise-architecture-finally-crosses-the-chasm/#65e4035852a5||Agile Enterprise Architecture Finally Crosses the Chasm||Jason Bloomberg||July 23, 2014|
|https://www.agilealliance.org/wp-content/uploads/2016/01/Agile-Enterprise-Architecture.pdf||Agile Strategies for Enterprise
|IBM Software Group||2010|
|https://bizzdesign.com/blog/enterprise-architecture-and-agile-development-opposites-attract/||Enterprise Architecture and Agile Development: Opposites Attract?||Marc Lankhorst||May 28, 2016|