Agile Procurement
September 2015
What is agile enterprise architecture?
Today, as much of the mainstream promotion suggests, absolutely every company must immediately adopt agile, otherwise it allegedly will not be able to survive the ‘digital transformation’ and perish tomorrow. Moreover, literally all aspects of organisations now must become agile, from software development to business models. And enterprise architecture (EA) is certainly not an exception. For example, Gartner hype cycle reports on enterprise architecture for both 2018 and 2019 conclude that ‘agile architecture’ is right at the peak of inflated expectations.
Similarly to many, if not most, current agile innovations, agile architecture has a strong positive connotation (who would not like to be agile?), but no particular meaning. For instance, one of the Gartner hype cycle reports offers only an elusive definition of this notion: ‘Agile architecture refers to architecture practices that embrace the principles and values of agile, which enable the continuous delivery of valuable software’1 (page 28).
Likewise, one of the recent academic papers defines agile enterprise architecture as ‘the process for infusing and managing enterprise architecture modelling and redesign efforts with principles of agile methods for faster development times’2 (page 1). At the same time, any more or less concrete descriptions or ideas on what specific practices constitute the phenomenon of agile architecture can hardly be found. Probably, the single thing that can be said for sure regarding agile architecture, is that it is definitely better than rigid architecture.
If we put aside all the incessant hype, anecdotal claims and consultants’ promises, then what will agile enterprise architecture look like? Seriously, all the discussions of agility can arguably be reduced to a single simple question that arises permanently in the organisational literature: ‘How much planning is enough?’
It is obvious that organisations cannot afford to neglect planning altogether (i.e. stay perfectly agile) as well as that organisations cannot pre-plan in every detail (i.e. be completely rigid).
For this reason, instead of trying to oppose agility to upfront planning as good to evil (or vice versa), organisations should think pragmatically and find an optimal position somewhere on the continuous spectrum between full agility and total planning. To put it simply, companies should avoid both the extremes and practise a reasonable amount of planning that corresponds to their unique business needs, circumstances and environments. This conclusion is arguably universal and relates to all manifestations of planning in organisations, including their EA practices.
My analysis of EA practices, in tens of diverse organisations, shows that EA practices, in fact, can vary across multiple weakly correlating dimensions that collectively determine their overall agility. Different aspects of an EA practice can gravitate either towards the agility extreme (more informal and lightweight approaches where more decisions are postponed) or towards the upfront planning extreme (more formal and heavyweight approaches where more decisions are settled in advance). Generally, less agile EA practices tend to match stable business environments and more agile EA practices usually correspond to dynamic environments, though this observation, as a substantial simplification, has numerous nuances and should not be interpreted superficially.
Due to the complex, overarching and multifaceted nature of an EA practice, it is difficult to compose an exhaustive and non-overlapping list of all possible dimensions of its agility. Hence, the discussion of the agility dimensions provided below, though intends to be rather comprehensive, certainly cannot be considered perfectly complete, while the presented dimensions themselves are not fully orthogonal and mutually independent.
An important group of agility dimensions relates to the process of strategic planning, where business leaders and architects collectively develop the global future course of action for business and IT (see The process view of enterprise architecture practice and Enterprise architecture practice on a single page).
One of these dimensions is the overall amount of time and effort devoted to strategic planning. Some companies invest considerable resources in the discussions of their future evolution, while other companies pay much less attention to these questions.
Another dimension is the organisational scope covered by strategic planning. Some companies embrace all their business units and areas in their long-range planning efforts, while others intentionally limit the scope of these efforts to a small number of core business areas.
A related dimension is the horizon of strategic planning. Some organisations plan for no more than 2-3 years ahead, but others need a five-year, or even longer, planning horizons.
Yet another relevant dimension is how the desired future is defined. Some companies create rather concrete descriptions of their target states, when others define their future only in terms of planned initiatives in investment roadmaps.
Another group of agility dimensions relates to the initiative delivery process, where specific business ideas and needs are converted into tangible IT systems and associated process changes (these dimensions naturally overlap with the domain of agile software development) (see The process view of enterprise architecture practice and Enterprise architecture practice on a single page).
One of these dimensions is the logical flow of initiative delivery. In some cases, initiatives are implemented in a strictly sequential, waterfall-like manner, while in other cases they follow highly iterative lifecycles (e.g. two-week Scrum sprints).
Another dimension is the volume of EA artifacts developed for initiatives, i.e. outlines and designs (see Six types of enterprise architecture artifacts, Eight essential enterprise architecture artifacts and Enterprise architecture on a single page). On the one hand, initiatives can be supported with very basic outlines and lean designs sufficient for informing business leaders on the proposed solution structures and documenting only the most critical project-related decisions (e.g. technology stacks, external integration and security requirements) respectively.
On the other hand, initiatives can be supported with rather elaborate outlines and extensive designs underpinning formal business cases with ROI calculations and providing well-thought-out project implementation plans sometimes spanning hundreds of pages.
Two dimensions of agility relate specifically to the finance allocation arrangements. One of them deals with the composition of corporate IT investment portfolios. In some companies, investment portfolios include mostly planned initiatives resulting from careful strategic planning, whereas in other companies they consist largely of urgent initiatives incoming directly from the external business environment (e.g. reactions to competitor actions) (see The process view of enterprise architecture practice and Enterprise architecture practice on a single page).
Another financial dimension is the structure of budgeting processes. Some organisations establish yearly budgeting cycles where all major investments must be approved and scheduled for the forthcoming period in advance, when other organisations adopt more flexible or even continuous budgeting procedures that allow funding proposed IT investments virtually at any moment during the year.
Two dimensions of agility relate specifically to architecture governance arrangements. One of these dimensions deals with the formality of decision-making processes. In some organisations, approvals of many EA-related decisions rely largely on verbal agreements reached between their stakeholders, while in other organisations all these decisions are officially protocoled and recorded.
Another dimension relates to the adherence to the approved plans. Some companies require strict adherence to the existing plans, when others are lavish on approving various exemption requests.
Two dimensions of agility relate specifically to architecture functions. One of them is the number of employed architects as a percentage of the total IT workforce. Some companies employ few architects (say, only 1-2% of their IT staff) and concentrate their efforts on a few key issues, while other companies hire hordes of architects (e.g. as much as 6-8% of their IT headcount) and involve them into all potentially architecturally significant discussions.
Another related dimension, is the degree of participation of architects in IT projects. In some organisations, architects supervise every more or less noticeable IT project, whereas in other organisations architects focus only on the most business-critical projects.
Lastly, EA practices vary in their agility from the perspective of technical standardisation and utilised software tools for enterprise architecture. Some companies develop comprehensive standards capturing each and every technology, pattern and guideline, while other companies standardise only the most essential technical choices (e.g. vendors and major products).
Some organisations leverage sophisticated commercial EA-specific software tools, while other organisations are content with ordinary MS Visio and PowerPoint for creating and managing all architectural documentation. All the dimensions of agility in EA practices discussed above are summarised in Figure 1.
Figure 1. Different dimensions of agility in enterprise architecture practices (click to view larger image)
From the numerous diverse and mostly independent aspects of EA practices that can vary towards greater or lesser flexibility (see Figure 1), it becomes evident that all the ‘binary’ discussions of agile versus non-agile EA practices represent sweeping oversimplifications of a very sophisticated organisational reality. Contraposing ‘a something’ called agile architecture to ‘a something’ called traditional architecture shapes a deceptively simple worldview and stimulates superficial thinking, that is best avoided. Instead of understanding EA practices in their full complexity, this worldview essentially tries to reduce them to two largely undefinable archetypes, both of which, in their pure forms, are unlikely to satisfy the needs of any real companies.
All in all, organisations and architects should stop fruitless ideological debates for or against the so-called ‘agile enterprise architecture’ and start thinking more realistically and pragmatically, i.e. determine the desirable degree of flexibility in different dimensions of their EA practices (see Figure 1) based on the sober understanding of the genuine needs of their organisations. Put it simply, companies should adopt planning to the extent to which it pays off in their unique circumstances, i.e. when the benefits of planning outweigh its overhead.
Different organisations are likely to require different planning approaches to meet their needs. For example, companies operating in relatively slow-paced industries (e.g. utilities) may find it beneficial to invest considerable efforts in organisation-wide planning, with an outlook to several years in the future, closely following the developed roadmaps and composing their IT investment portfolios on a yearly basis, predominantly from the planned initiatives.
By contrast, companies from highly dynamic industry sectors (e.g. retail) may find it more suitable to plan selectively only in certain business areas and only for a couple of years ahead, loosely following the envisioned roadmaps, launching mostly urgent initiatives to respond instantaneously to the latest shifts in the competitive environment (e.g. fleeting customer preferences and fashions) and adopt continuous budgeting processes to accommodate these demands.
Moreover, the appropriate degree of agility can also differ for different types of initiatives in the same organisation. For instance, it is commonly acknowledged that agile canons can be applicable mostly for simple, run-of-the-mill software projects, while complex and especially infrastructure-heavy projects still require substantial upfront planning3. For this reason, organisations should not try to impose the same solution delivery methodology for all their IT projects, from routine website enhancements to large systems mixing software and hardware components, but rather adapt the methodology to the task at hand.
Finally, at the peak of hype around agile, in their selection of effective planning approaches organisations must make decisions for themselves, rather than rely on the advice of gurus, consultants and ‘thought leaders’ – especially those advocating irresponsible one-size-fits-all prescriptions or dangerous extreme views (e.g. old-fashioned formalists promoting the benefits of following ‘proven’ TOGAF ADM steps and eager to earn $3000 from the respective trainings as well as progressive agilists preaching that enterprise architecture is allegedly ‘dead’, unnecessary and should be completely abandoned in favour of greater agility). Such ideas can be harmful to your company.
Nobody can know what planning approaches are suitable for your business better than you and nobody should be allowed to make these decisions on your behalf. Therefore, do not follow the hype blindly and do not try to implement the latest fashionable ideas, just because they are widely promoted. Think what approaches can actually work in your situation and adopt them wisely.
Originally posted here
