I was catching up on some e-mail this evening and noticed a thread started by Steve Godbold about any possible trade-offs between agile software development methods and enterprise and systems architecting/modelling. It is an interesting question and probably deserves a bit of discussion.
What is agile software development?
Most developers would these days say they practise some kind of agile software development. There are quite a few different methods out there but the common thread amongst them is the incremental delivery of value within an iterative development model (although some methods have iterations so small that it could be considered a steady flow of value).
In a lot of ways, the definition of agile software development is fairly well understood whereas the implementation details are often argued about.
What is enterprise architecture?
Enterprise architecture could be defined as the relationship between the various supporting information systems within an organisation and an understanding of how they integrate with business processes and the overall business strategy for an organisation. Anyone who talks about a specific system without an overall picture of how that system fits within the organisation is practising systems architecture at best, but certainly not enterprise architecture.
What is systems/application architecture?
Systems, or application architecture is a more local focus for architectural efforts. It defines the ideal design of a piece of software given the functional and non functional requirements. For example an application that required immediate consistency on all transactions might need to avoid a number of the NoSQL persistence options out there – its all about the application specific trade-offs that you need to make.
It’s all about value!
Agile methods, enterprise architecture, systems/application architecture all exist to deliver value to the business. Agile methods deliver value by reducing the risk of project failure by delivering value in small incremental pieces.
Systems/application architecture define the overall picture of how the application will come together and is good at “taming” the emergent design that you often get in agile development projects. I wouldn’t go into a project without a reasonable idea of how the pieces of the system are going to integrate together and identify which technical aspects of the system are risky and need to be spiked out.
Enterprise architecture is really playing at a different layer of an organisation. A good enterprise architect is going to be deeply integrated with the business units and know what their current challenges are and have a plan for how those issues are going to get resolved over time. It pushes some design constraints onto agile projects by defining what kind of interactions that new system needs to support – the value it provides is that longer term vision.
Muddy waters of enterprise and systems architecture.
In my experience a lot of organisations confuse enterprise and systems architecture and tend to collapse it into a single role. If you are in this kind of role you need to work hard to not turn each system into a microcosm of the overall enterprise architecture and in the process completely overcomplicate the problem at hand. This threatens the ability of both disciplines to deliver value and can completely derail an agile team.
Enterprise architects are chickens, systems architects are pigs!
Is everyone sick of the chickens and pigs analogy yet? Systems architects really need to be involved to the bitter end of a software development project. Along the way the architecture will be challenged and it may need to evolve rapidly on the spot. Enterprise architects don’t necessarily need to do this because their influence is really exerted on the functional requirements of the system being developed.
I’ve seen heavy handed architectural approaches fail with agile development teams where they couldn’t effectively manage their technical debt because of an inappropriate architecture (just because you call it an architecture doesn’t mean it is correct, and the best way to test an architecture is to start to test it by building against it). Conversely I’ve seen agile development teams produce steaming piles of crap simply because they didn’t have a high level overview of how the system would come together.
The best agile development teams treat systems architecture as an evolving item where you know roughly which direction you are heading but keep your implementation open for change and it is this that delivers value to the organisation and allows enterprise architects to evolve the overall systems of the enterprise more easily.