Enterprise Architecture as the CIO’s Digital Business Advisory
Digital business demands a new perspective to Enterprise Architecture (EA). What architects are responsible for has had to be revised, as the industry has demanded a more hands on EA contribution. The once support-only domain has transitioned into a business asset essential in business transformation, and expanded to require innovation from its practitioners.
Many industry analysts have even advised a two pronged approach to Enterprise Architecture (known as ‘bimodal’) – whereby organizations proactively recognize both the fact that enterprise architects have new responsibilities, and the fact that these new responsibilities are very different from the old.
It’s this evolution of Enterprise Architecture that is responsible for moving EA closer to the center of the organization; directly liaising and even advising the CIO.
Business Outcome Driven EA and its Benefits to the CIO
Industry analysts have been championing ‘businsess outcome EA’ for some time now. Brian Burke, Gartner analyst said: “Focusing on a standard EA framework doesn’t work. In the past EA practicioners focused on deliverables that were useful to enterprise architects but not valuable to senior management and/or did not respond to a specific business IT need.”
“We’ve witnessed a change in mind-set, execution and delivery of EA. The value of EA is not in simply ‘doing EA’, but rather in how it can help evolve the business and enable senior executives to respond to business threats and opportunities.”
This take on EA fundamentally requires the EA team to liase with business leaders, with their input considered a valuable insight into strategic planning and the execution of strategy itself. This requires empowering EAs to be the driving force behind transformation, as well as delivering high-impact value.
Consider the role of the Chief Information Officer. The CIO must ensure that the relevant business assets are in place for the organization to execute strategy, and achieve the goals, objectives and vision set out by the CEO. This means business processes, applications, technology, information and other assets must be accounted for and aligned in order to not only meet said objectives, but to do so efficiently, avoiding redundancies wherever possible.
Furthermore, it’s important that the execution of strategy, is organization wide. That doesn’t mean that every department has to grow and change in the same way, but it does require an inter-departmental understanding to make sure investments in one part of the organization do not conflict with another.
This is why the business outcome approach to EA is such a useful asset to CIOs. They can be a great source of ideas and suggestions for the CIO to take to the business for discussion.
Enterprise Architects are in the unique position of having a macrocosmic (top-down/company wide) view of the enterprise. The most immediate benefits of this is that EAs have a more clear view of areas of potential risk and disruption. However, the up sides go deeper than that. As well as being able to spot threats, the Enterprise Architect’s macrocosmic view of the organization and its systems also provides them with insight into opportunity.
In short, EA’s are best positioned to see where a system or process could be improved, re-purposed, or in cases of redundancy, axed.
The Enterprise Architect’s perspective on the business can inform the CIO of the organizations current, and future state potential through the application of Business Capabilities for example, ensuring resources are spent in the correct places drive the organization forward towards its business goals.
|An example Business Capability View|
What Can Enterprise Architects Do to Make It Happen?
Much has been made of EA being an ‘Ivory Tower’ discipline. In many organizations, EA teams struggle to move through markers of maturity due to a lack of investment from business leaders. However, as the section above details, this isn’t down to a lack of value – rather it’s down to difficulty in conveying the value. Enterprise Architecture is a complicated domain that requires experts to manage, but it doesn’t need experts to interpret. Not if EAs don’t needlessly over complicate the procedures.
Applying modern Enterprise Architecture mantras and best practices, goes a long way in simplifying the message for stakeholders and other relevant, non-expert parties. Not only will this go a long way in helping bring EA closer to the center of the business, it will also aid in securing the funding and attention required to mature the EA department.
One of the best places to start, is a relatively new approach to enterprise architecture – collaboration.
Sure, collaboration has been a characteristic of EA for some time – but arguably, only by name. Simply sharing the outcomes of EA after the fact does not constitute true collaboration. Collaboration requires a shared experience in the whole EA process. This means clear and recognized methods of feedback such as in tool comment support; role based access with real time updates to the architecture – including roadmaps, concept attibutes and models – keeping everyone updated; the introduction of in tool Kanban boards and encouraging engagement through gamification. Establishing a digital business platform that can facilitate this is a great first step in maturing the department.
Another best practice to employ, is ‘Agile EA’. In Enterprise Architecture, agility refers to how soon the department (and the wider organization) can respond to disruptions, the time to market, and so on. To reach peak agility, EA teams should work within the parameters of ‘Just Enough’ and ‘Just in Time’ Enterprise Architecture.
This is particularly useful to stakeholders as it means they’re only presented with essential information, and not the irrelevant data that can muddy their interpretation of EA’s value.
For low maturity EA departments, those doing Visio, Powerpoint and Excel based EA, stressing the limitations of such set ups to decision makers is a must. Office Tools Enterprise Architecture is a great, low cost method of starting EA, but once the architecture begins to develop, it can become extremely difficult to manage, incredibly fast.
Not only does having to manage three separate programs, with disconnected file types, updating each individually, vastly increase work load, it also makes it extremely complicated to share with anybody else. In many cases, these sorts of architecture set ups are absolutely reliant on the architect that put them together. Only they know where this project, or that project is stored and when it’s time to collaborate, or even replace the architect after they’ve left, the headaches this can cause are significant.
This type of EA can even lead to the architecture literally outgrowing the tools, with models and diagrams extending out of their digital habitat onto scraps of paper and post it notes to keep track.
Enterprise Architecture’s shift in focus is now well documented. The discipline has reached well beyond simply protecting the organization, defining processes and systems, and setting standards. The most mature EA set ups now recognize the evolution of the job role officially, distinguishing between the ‘foundational’ (traditional EA) and ‘vanguard’ (the new EA) architects – more on Foundational vs. Vanguard EA’s here.
The evolution of EA has provided Enterprise Architects with a new opportunity to redefine their importance in the organization, but architects won’t get there by default. However, remembering principles such as Agile EA, Just in Time, Just Enough, and placing a new emphasis on true collaboration will help turn EAs into the perfect advisory team to CIOs.