Enterprise architecture – or, more accurately, corporate IT architecture – as a discipline within a company’s IT operations, does not have an easy time of it. Often criticised as ‘too cumbersome’, ‘too unwieldy’ or simply ‘too complicated’, very few companies dare to introduce the relevant processes and frameworks. This is because there is a great deal of respect for the complexity of frameworks such as TOGAF or Zachman. And, in truth, people would rather focus on technical issues.
Enterprise architecture isn’t something you can just ‘do on the side’ or ‘whilst you’re at it’. After all, it involves aligning the business purpose with IT operations and ensuring they work in tandem. Ultimately, IT operations must be measured by their contribution to the business purpose. The search for optimal IT solutions to a specific operational challenge is often complex; standards must be defined, new processes and coordination rounds established, and numerous documents drawn up. So there is plenty of potential for conflict. But therein also lies ‘potential’
Slicing the elephant
To align IT operations with the company’s objectives, it is necessary to identify and describe business processes. This immediately leads to a better understanding of the business processes, their value (or their potential to create value) and their respective levels of complexity. Even at this stage, organisations can derive valuable insights from the data collected: for example, where are the risks in the process chain, where might there already be opportunities to reduce complexity, and do all stakeholders share a common understanding of the relevance of the processes?
Subsequently, the existing IT processes can be mapped against the business processes and assessed to determine whether they optimally support the intended purpose, whether the effort involved in the IT process is proportionate to the value creation of the business process, and whether it aligns with the risk assessment of the business process.
If the ‘Enterprise Architecture’ project were to be halted at this stage, a great deal of useful information would already have been gathered for senior management and IT management. But Enterprise Architecture is not a ‘business studies pentest’. It is only now that the work begins to identify potential for optimising existing processes and to establish the appropriate framework for future decisions.
Better done than perfect
So far, we have not discussed frameworks and will (almost) continue to avoid doing so. Enterprise architecture tools (such as EA or ADOit) are valuable and helpful; TOGAF and Archimate are too. But at its core, an enterprise architecture can also be mapped out using pen and paper, or with Visio, diagrams.net or Xcalidraw.
So how and where should you start? Please don’t wait until conditions are ideal – it has proven effective to test your approach on one or two business processes. This involves:
- Describing the business processes and their interfaces with other processes (however and wherever you choose): To begin with, this could be a single process, for example (‘How do I order new consumables?’). It becomes more comprehensive with an entire process chain (“How do I dispatch goods to my branches?”).
- Identify the IT processes used for these business processes and incorporate them into a central diagram. Here, it is advantageous to use a CMDB suitable for enterprise architecture processes. To begin with, this could be an existing asset database (e.g. from the JIRA ecosystem) – but in the long term, it is advisable to use more specialised CMDB applications from leading providers of Enterprise Service Management (e.g. OpenText, BMC or ServiceNow). Dependencies and risk chains quickly become apparent.
- Assess the architecture: Do the processes and infrastructure in use meet the requirements for availability and resilience? Are the costs incurred in delivering the service reasonable? Is the architecture in use fit for the future?
- Evaluate the results: The data gathered so far is invaluable as a basis for further analysis (such as risk assessments and application portfolio management), as well as for IT operational processes such as change, problem or enterprise service management.
- Document it!
You will soon find yourself expanding the picture that has emerged, recognising more and more dependencies and identifying redundancies. Along the way, a standardised vocabulary will emerge, along with a granular view of the organisation’s IT infrastructure, featuring refined and improved asset management, and a very clear understanding of which processes need to be developed next.
