Unless we re-think Enterprise Architectures (EA), and bring it into alignment with the agile development movement, we may be in for a collision between two cultures.
Here at Info-Tech world headquarters, we are working on a series of project blueprints on agile development (more about that below). I’ve been involved quite a bit in quality reviews of these blueprints and have started thinking about the impact of agile development on Enterprise Architecture. I see the implementation of EA as being at odds with the Agile Manifesto. Here’s the manifesto, in case you haven’t seen it in a while:
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.
Enterprise Architecture, as currently implemented in large organizations, tends to favor the items on the right over the items on the left. The stock in trade of EA consists of processes, tools, comprehensive documentation and creating plans for others to follow. As agile development grows within large organizations, something clearly has to give.
Reinvent, Oppose, or Meet in the Middle?
Can Enterprise Architecture reinvent itself as an agile practice or must it, by its very nature, oppose agile development as yin to its yang? Or should agile and EA meet somewhere in the middle?
Those of us with many years of IT experience sometimes shudder at the thought of the agile manifesto. With the gift of 20/20 hindsight, we look at the tangled mess of systems built in a typical IT shop over the last 30 years and wonder if a little planning might have saved the day. If we were guilty of anything, it was being too responsive to our business users.
Instead of building that fifteenth billing system because the user’s product line was special and needed to launch yesterday, maybe we could have insisted on re-purposing an existing system and saved the company from the burden of duplicate customer databases, nineteen different customer identifiers and revenue reports that don’t reconcile. Do we really want to become even more responsive and adding to the spaghetti that is already strangling the typical IT department in a huge technical debt that soaks up 80% of the budget?
On the other hand, our business users are so fed up with the slow pace of IT that they are taking matters into their own hands and implementing cloud solutions left and right. If we insist on rigorous central planning, we’ll end up managing yesterday’s IT department and wondering where all the new applications went.
The Road to Re-invention
Clearly, we need to re-invent Enterprise Architecture to retain its best features and avoid technical debt while adapting to the new realities of agility and the cloud. How on earth do we do that?
Here are some of my early thoughts:
- We need to focus on high-level principle statements and vision diagrams that can communicate the essence of our target state quickly. Our audience now consists of people who have grown up with sound bites, infographics and video games. If we can’t communicate to this audience, we are lost before we begin.
- Our revision cycles have to speed up and adapt. The ponderous Application Development Methodology (ADM) that forms the heart of TOGAF doesn’t cut it anymore. Our architects need to become part of the agile teams, contributing to the development of working software and constantly feeding back to agile EA teams who are actively maintaining the integrity of our target state vision.
- The various core practices of architecture (business architecture, technical architecture, data architecture etc.) need to be practiced simultaneously in agile sprints, not in sequence.
- The notion of architecture governance, based on review gates and review boards for large waterfall projects, must be discarded and replaced with a “roll your sleeves up” approach that embeds architects with agile teams so that they can practice governance in real-time. This will avoid costly rework when teams fail to meet standards and adhere to guidelines.
- The holy grail of a fundamental repository of re-usable artefacts must finally be set to rest. Artefacts rarely, if ever, get re-used and no one ever trusts the state of current documentation as an accurate representation of the actual state of the application. Let’s get over it and be practical.
Please note that I’m not advocating any abdication of EA responsibility. We need a clear central vision of what we’re building to avoid technical debt and ensure that systems mesh together well. However, the way we accomplish this must change with the times. We need to be able to clearly and quickly communicate our vision and become active evangelists for it, contributing to real work as we encourage our team members to do the right things.
Those Info-Tech project blueprints on agile I mentioned above include Agile Practices that Work. This blueprint is aimed at organizations implementing agile technologies for the first time and is a no-nonsense practical guide to implementing scrum. A second blueprint called Increase the Agile Footprint, currently in production, is focused on optimizing the application of agile methods and gaining momentum in the organization for the roll-out of agile to more projects. The third and final blueprint will be aimed at scaling up agile methods to take on large projects and will be based on the methodology created by Scott Ambler, called Disciplined Agile Development.
We are also thinking about creating a blueprint on this subject of re-inventing EA for the Agile Movement. I welcome your thoughts and experiences. Has anyone out there implemented agile enterprise architecture in some fashion?