By The Open Group
On April 27, the second TOGAF® User Group Meeting was held at The Open Group London 2016. The session brought together TOGAF users and stakeholders to share information, best practices and learning, for the development of individual practitioners’ knowledge and the standard as a whole. Discussions revolved around how to better use TOGAF in practice within different organizations and industries, success stories and areas of improvement, as well as suggestions as to how the standard can be improved upon in the future.
Central Hall Westminster conservatory was packed, as Steve Nunn, President and CEO of The Open Group, opened the meeting with a warm welcome to the community. He heralded the session as an initiative that was ‘trailblazing’ the way for the development of TOGAF®, an Open Group standard, which now has more than 55,000 certifications.
The session was hosted by Terry Blevins, a Fellow of The Open Group and Director of The Open Group Governing Board. Terry has been involved in development of the TOGAF standard for years and has been a major contributor to its development. He stressed that as the community continues to grow, it’s so important to hear real-world experiences of those using the standard to get a broader perspective on what works, what doesn’t, and how it can evolve.
To achieve this, the TOGAF User Group staged an ‘Open Debate’. Fashioned on an Oxford-style debate, it was designed to tap into people’s feelings about the TOGAF standard and allow questions and different points of view to be shared around the room. Standard debating rules were explained, before the proposition declaration was laid out:
“The TOGAF® Architecture Development Method (ADM) is not agile and therefore there is a need to change the specification to make it agile.”
Arguing ‘For’ the proposition was Chris Armstrong, President of Armstrong Process Group, Inc. and internationally recognized thought leader and expert in iterative software development, Enterprise Architecture, object-orientated analysis and design, the Unified Modelling Language, use case driver requirements and process implementation.
Arguing ‘Against’ the proposition was Paul Homan, Technology Strategy Consultant for IBM for eight years. He is a Certified Distinguished IT Architect, specializing in Enterprise Architecture joining IBM from end-user environments, having worked as Chief Architect in both the UK Post Office and Royal Mail. Not only has he established Enterprise Architecture practices, but also lived with the results.
Open Debate with Paul Homan and Chris Armstrong
In order to understand the audience’s view at the outset of the debate, attendees were asked to vote on their existing standpoint. A few hands showed support for changing the specification to make it agile, and a few abstained. However, most hands were raised against the proposition, agreeing that the ADM was already agile in nature.
Chris then had seven minutes to argue his case – that the TOGAF ADM is not agile and needs to change. He conceded that very few people would steadfastly ignore change within their organization and aim to respond to it badly, however in the whole 692 pages of TOGAF version 9.1, agile is only mentioned twice, agility 6 times and lean is not mentioned at all. Furthermore, the mere fact that there are 692 pages could be taken to indicate the lack of agility altogether. The crop circle diagram that underpins the whole framework appears linear and waterfall in appearance, and so lacking in agility by nature. He argued that the only way that the TOGAF ADM can realistically support an agile enterprise is by becoming agile itself.
Likewise, Paul put his seven-minute case forward – arguing that the TOGAF ADM is agile and does not require any changes to make it so. He made the point that as an architect, everything has to have a reference system, and that the TOGAF ADM is a framework for developing architecture, not a style guide. The specification is actually part of a wider ecosystem of material, including pocket guides, whitepapers, translations and qualifications, and all of these items help to move the enterprise away from project management bureaucracy, towards agile project development. Enterprise Architects, he said, should live by the oath: ‘I will apply for the benefit of the enterprise, all architecture practices that are required’. This is so as to make agile more meaningful and relevant. Instead of relying on the framework, agility is created through just enough architecture, coupled with the interpretation and implementation of the framework by the practitioner. Therefore, skills are the most important element in these projects.
Following these opening statements, TOGAF users were encouraged to ask questions to the pair. A couple of these, included below, give a flavor of the discussion:
Q: Chris, you counted the number of times TOGAF uses the word agile – but how many occurrences are there where it says you cannot be agile and processes must take a long time?
A: Chris –Just because TOGAF does not say you cannot be agile, does not mean it is agile itself. The best laid plans will not work if the people delivering it do not see where they fit in and translate their work to the project they are implementing. We are not recognizing significant changes in delivery from the waterfall practices of many years ago.
Paul – It’s a prioritization exercise – we need to worry about the behaviors of practitioners and the interaction of enterprise architecture functions within a project, rather than the spec and other incentives. Accessibility is key – we can help people access this body of knowledge without having to rethink the whole body of knowledge
Q: The TOGAF standard is a reference model and we need to adapt to the particular needs of each organization, so how do you handle that?
A: Paul – It’s all about consumption. We have to consider that somebody has to be able to consume the guidance that we want to provide as EAs within a development project. We want them to be aware of what matters to us from an EA perspective – we shouldn’t be trying to out-design them, we should just think about what is relevant to us that they are potentially not aware of. This comes back to understanding your consumer.
It’s a bit like someone that comes to service the heating in a house. The consumer is the house owner and the servicer has a tool bag, which in this case is the TOGAF standard. It has all the tools in it you might need. Boilers will change, but what is really changing in an agile world is that customer experience is evolving. This would include their presentation, reliability and professionalism – customers get a good experience from behaviors and style, not the toolset. The tool bag will remain the same, but behavior and how it is applied needs to change and get better.
Q: Chris, are you saying that we should be working in a completely agile fashion and that waterfall methods are no longer relevant?
Chris – We need to acknowledge the complexity of various different organizations, and we need to find the balance between always evolving technology and approval times, for example. Agility in enterprise architecture is often compensating for a lack of agility throughout the rest of the enterprise – maybe solution delivery teams wouldn’t have to be so agile if everywhere else in the company was a bit more agile.
Q: The crop circle is a waterfall model, this is reflected in the spec itself, but if you keep the framework are we missing the opportunity to address different levels of agility?
Chris – We need to change the crop circle. This might be met with great resistance but it implies that you have to wait to complete one phase to start the next one – you should be doing certain processes every day and not waiting to go from one stage to another.
Paul – The reader is lulled into the idea that there is a sequence and you must complete one phase before another. I think that there is always going to be a weakness in condensing a large body of knowledge into one diagram, and there is always going to be approximation which is what has happened from TOGAF® 9.1 into the crop circle. There are things we can assume – but this is why the spec says it’s not intended to be waterfall.
The two speakers then summarized their arguments. Paul reinforced his argument that the ADM is fit for purpose as a Hippocratic Oath for EAs, but what matters is the changes in our behavior to complement this. Chris stated that the spec does need to change, to add supplemental guidance so people can be guided in how to implement TOGAF as an agile framework.
When it came to the final vote from the audience, more people had been persuaded by the ‘for’ argument, to change the ADM spec, however the ‘against’ argument still had more support in the room. This conclusion demonstrated that there was a display of two sound and compelling arguments for each side, and Terry noted that more time for questions would be needed at the next debate!
Following the debate came two breakout sessions; ‘The Roles of People in TOGAF Driven Architecture Initiatives’ from Len Fehskens, Editor, Journal of Enterprise Architecture (AEA), and ‘Using TOGAF® for Digital Business Transformation’ from Sonia Gonzalez, The Open Group Architecture Forum Director. These sessions were used to open up a freer dialogue between users, to discuss their ideas and experiences around the TOGAF standard.
Check out video highlights of the debate here!
Please join us at the next TOGAF® User Group Meeting taking place at The Open Group Austin 2016 July 18 – 21!
@theopengroup #ogLON #ogAUS