Enterprise Architecture and Agile Development: Opposites Attract?
May 28, 2016
Agility has become a key ability of enterprises. The pace at which customers require changes, at which new laws and regulations affect services and introduce processes, and the ease with which competitors can disrupt your business, as Google and Apple do nowadays, leads to tremendous pressure. Pressure to change rapidly, to adopt new technologies, to generate growth, to scale up or to reduce cost.
So in many organizations, being agile is as crucial as being able to innovate. Innovation and agility are necessary competences for a sustainable business.
Scaled Agile Framework
Agile development has become the norm for software development. But true business agility requires more than having a bunch of Scrum teams. Moreover, if you only focus on the small-scale kind of agility provided by agile software development, you might not see the forest for the trees: why do you want to be agile as an enterprise, and what does that require?
An enterprise is more than just a bunch of local developments by small teams. The pieces of the puzzle that these teams work on, must fit together somehow. And hopefully there is a vision of the future, a business and IT strategy, a set of goals that the organization aims for. That is where enterprise architecture comes in.
Traditional enterprise architecture has a rather top-down character, where you draw up extensive plans before implementing them. The agile movement with its focus on adapting to change and resistance to ‘Big Design Up-Front’ (BDUF) is rather the opposite.
Both approaches have their merits and shortcomings. Traditional EA may lead to slow and bureaucratic organizations that don’t know how to move with the times, and only having a horde of Scrum teams without some integrative, overarching approach may lead to a disconnected IT landscape consisting of agile silos. However, if we build on the strengths of both approaches, we can create enterprises that move as a united whole without having a central, command-and-control management that stifles local development and innovation.
Modern developments such as the Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD) move in the right direction. Let’s take SAFe as an example, depicted in simplified form in the figure below.
Agile EA with TOGAF 9.1
SAFe uses a layered, iterative approach where we find the typical agile teams in the bottom layer. These deliver their results in a typical agile frequency of 2-3 weeks. In the middle, the results of these teams are integrated and released using solution architecture concepts like the Architecture Runway and the Agile Release Train, which ensure that these fit together. This layer iterates at speed that is a few multiples of the team layer, delivering potentially shippable products every 2-3 months. At the top, the large, longer-term developments are positioned. This is where enterprise architecture finds its place. The business strategy feeds into this layer and provides the context for large-scale, high-impact architecture decisions, priority setting and budget allocation.
In this top layer, established enterprise architecture methods such as TOGAF find their place. TOGAF also has an iterative structure, shown by the familiar ‘crop circle’ diagram of its Architecture Development Method (ADM). Applying it in an agile context will require some adaptation, though. In particular Enterprise Architecture will need to become more outward-looking and consequently more business oriented, end-customer and outcome-focused. A business outcome could be an end-customer product, which is described by services, capabilities, deliverables and artifacts, but also a business transformation that implements a new strategy.
Looking to TOGAF again, the way in which TOGAF’s Implementation Governance (Phase G in the ADM) interfaces with implementation projects and programs (i.e., the bottom two layers) needs some work. In particular, agile methods strongly rely on feedback loops, whereas TOGAF’s governance is rather feed-forward in nature. TOGAF’s Architecture Change Management (Phase H) is a useful entry point for this feedback. We intend to address this in one of our future blogs.
Moreover, SAFe, DAD, TOGAF and related methods are still rather IT-centric. According to SAFe, the role of the enterprise architect is to “[…] drive holistic technology implementation […]”. But a true enterprise architect is not focused on technology alone. Rather, business architecture is an increasingly important part of the equation: strategy mapping, capability-based planning, value mapping, business process management, Lean Six Sigma and other business-related disciplines are still missing from the picture. A truly agile enterprise needs more than agile IT alone.
Stay tuned for more on Agile & EA and in the meantime, let us know your thoughts on these issues.
