Agile and Enterprise Architecture

Transcription

1 08 Experience, Intelligence, Pragmatism, Commitment. Always striving to ensure outstanding delivery Agile and Enterprise Architecture Steve Marchant July 2013 Abstract The IT industry is evolving at an unprecedented rate, looking for innovative ways of transforming businesses with better outcomes and shorter timeframes. But often, different initiatives are not immediately compatible with each other because they are often pursued individually to address different problems and concerns. However, the need for alignment emerges as organisations see benefits of more than one individual approach. This paper considers two key initiatives, namely Agile Development and Enterprise Architecture, and illuminates some key executive and management considerations when organisations want the two to work together effectively. This whitepaper is based on our experience in a variety of delivery programmes across several industry sectors. ASE Consulting 73a, Clifton Street Lytham, Lancashire, FY8 5ER, United Kingdom e- mail: [email protected] web:

2 Competing Methods? When I first heard the buzz surrounding Agile Development I was very jealous. I was jealous because for Developers there was some real momentum building behind a methodology that tries to deliver something of value more quickly, more relevant to the business and with less risk. Enterprise Architecture (EA) was still missing the point and had not fully embraced that closeness with the business or the need to deliver results more rapidly. Most businesses can no longer wait for long, waterfall style development cycles, nor can they wait for Enterprise Architecture to fully understand the Enterprise, which is often what it tries to do over too prolonged periods. There is an important role for both Enterprise Architecture methods such as TOGAF 1 and Agile Development but how do we get them working together effectively? Working software over comprehensive documentation Customer collaboration over contract negotiation and Responding to change over following a plan. It goes on to state that the items on the right [of the statements] are still valuable; but the items on the left are valued more. EA Pitfalls Because EA methodologies such as TOGAF try to be comprehensive and apply structure to architecture development there is a danger that its techniques are, in practice, applied too rigidly. Here s how the TOGAF Architecture Development Method (ADM) is often applied: Agile Principles Agile Development was described in the Agile Manifesto 2 in 2001 and although not its primary focus, many would classify it as an iterative development method. It follows a long line of initiatives that have moved software development away from ridged Waterfall methods to more iterative approaches such as the Rational Unified process (RUP), Scrum, Extreme Programming and Dynamic Systems Development Method (DSDM). All these methods introduced concepts that led to the Agile Manifesto but it goes much further in its principles. The manifesto states simply that - we value: Individuals and interactions over processes and tools Recognise this? It s like a waterfall model of development. Although TOGAF certainly did not intend this, it is a pitfall many practitioners fall into with Enterprise Architecture and few make it even to phase E (Opportunities & Solutions). 1 The Open Group Architecture Framework 2 Beck, Kent; et al (2001) Manifesto for Agile Software Development TOGAF s famous wheel, when looked at with Agile eyes makes a lot of sense. 2

3 In some respects, understanding the Agile principles and methods and then doing Enterprise Architecture following those principles will lead to more effective application of the TOGAF Architecture Development Method (ADM) and delivery of valuable business products. TOGAF tries to solve this problem of application but has not yet hit the nail on the head quite in the way Agile has. So why not simply blend the two approaches? There is no reason why EA cannot use more of the principles of Agile Development Here, prioritisation, iteration and segmentation (of a business problem) are completely acceptable. Choosing the phases that add most value at the right time in a project, using iteration to start at a conceptual or high level and working hand in hand with the business before dropping into detail all surface when you realise the ADM 3 can be applied in an Agile way. Staying high level, deferring lower level decisions and delivering architectures early and regularly can provide an order of magnitude more business value than executing every phase linearly and to the n th degree of detail. Agile Enterprise Architecture What Agile recognises is that operating at a distance from the business is not effective, and nor is inflexibility to change because now more than ever businesses do change. Agile breaks development down in to small manageable chunks (sprints) and delivers in weeks rather than trying to deliver a complete solution in months or years. Pragmatic application of Agile Here is my top five list of Agile concepts that can be easily applied to Enterprise Architecture: 1. Don t be a slave to processes or tools. The TOGAF ADM is an excellent guideline but it s only a guideline. Equally, while tools can help organise information it is the talent and behaviour of people / architects that make the difference in terms of business value and rate of progress. Give me a good architect and a whiteboard any day. 2. Engage the business and collaborate rather then tell them about your architecture. Like Agile teams, why not have an experienced business representative embedded in your architecture team? 3. Develop architecture in a language the business understands and keep it simple. There is often a temptation to deliver hundreds of pages of UML 4 and catalogues when a few pages of a well illustrated concept is all that is needed to make a business decision before you let your Agile development team loose. 3 Architecture Development Method 4 Unified Modelling Language 3

4 4. Develop architecture to support the next specific delivery objective in detail while maintaining a wider conceptual view and continually validate with the business. Don t reduce your flexibility to change by spending time on too much detail too soon. Be prepared to change and to rework architecture. 5. Strive for simplicity in everything. If architecture looks complex or people can t grasp it immediately, you ll struggle with stakeholder buy-in, decision making and implementation risk. Engage the business and collaborate rather then tell them about your architecture How to get going Remember that not all projects are suitable for Agile Development and this also applies to Enterprise Architecture. Start by using the TOGAF Preliminary phase to assess the project, its scale, the people involved and the nature of the problem space. Consider training people in Agile methods, team behaviours, working relationships and work management as a pre-requisite to EA. In many ways the fact that Agile is focused on development belies the value of the approach to other IT disciplines. Think about team-building activities across business and IT. I can hear the moans now, but effective team building develops behaviours that can mean the difference between success and failure and have a massive impact on time to market. Team behaviour is a significant pillar of Agile and somewhat less mature in TOGAF. And here s the nub how many organisations do you know who have a separate enterprise architecture team / function? And how much traction do you think they have with the business and what business change / delivery can they directly account for? While an overall enterprise view is essential, shouldn t your EA practitioners be embedded in your project delivery teams? Agile currently works better for smaller projects (e.g. fewer people / function points) while EA works better for larger ones. But also consider complexity, degree of innovation, stakeholder buy-in and other risk factors. Developing an application is very different to developing an enterprise of integrated processes and systems. 4

5 Summary Both Agile and Enterprise Architecture have developed over many years and are undoubtedly here to stay. They are both valid and both add value to the right kinds of business change projects. However, both have to be applied intelligently. In the wrong hands Agile projects can iterate indefinitely and Enterprise Architecture teams can get lost in irrelevant detail. But an intelligent application of Agile principles really can fill some of the gaps in Enterprise Architecture approaches, particularly in team behaviour, business involvement and delivery focus. At ASE Consulting we use a variety of methods and tools but we mostly rely on experience. We can, and do, combine the best of Enterprise Architecture practice with Agile methods across our public and private sector clients. What we have learned is that no single textbook has the answer so we base our experience broadly and intelligently. And we are very happy to share that experience. About the Author Steve Marchant is a Managing Consultant at ASE Consulting. He has over 20 years experience in Information Technology covering a range of industry sectors in both the private and public sector. He has been instrumental in delivering a number of high profile consulting projects. He also leads the ASE Enterprise Architecture practice and has a passion for delivery focused architecture and high performance teams. ASE Consulting was founded in 1987 and is established across a side range of markets, providing high quality services in bridging the gap between business and technology. We have a proven track record in delivery results to clients through our core service offering of Enterprise Architecture, Programme Management, Information Assurance, Commercial, Telecommunication and Operational Efficiency. 5