Quantitatively Aligning Business and Technology
As enterprise architects we are frequently asked to provide a view into how well our systems, infrastructure and applications support our businesses. These analyses can be used to prioritize investments, redirect resources, plan new applications, and understand the impact of business and technology changes.
Of course, there are numerous EA frameworks and methodologies to help you do this, perhaps the most famous being the Zachman Framework, created by IBM’er John Zachman back in the 1980’s. The simple “who/ what /where/ why/ when/ how” structure of the framework is both intuitive and appealing, essentially providing a structured drilldown from the business problem to the technical implementation. While the Zachman Framework is more of a classification ontology (although several groups offer practitioner courses), TOGAF provides a high-level stepwise methodology for project implementation.
Still, I find great utility in two specific metamodels,business capability modeling and process modeling. (These fit well into Zachman and TOGAF; they are useful tools in either framework.)
Capability modeling hierarchically examines what your business does. Most companies have top-level capabilities around selling, manufacturing,finance, customer support and resource management. These can be decomposed into component capabilities (lead generation, pipeline management, and so on); five or six levels is usually enough to get a useful, detailed view of what your business does.
You can decorate each capability with attributes, such as the maturity of the capability, whether it is automated or not, who does it, its overall cost, and so on. It’s often fascinating to see how level 5 or 6 capabilities are often duplicated across higher level ones (lead generation might be a function of both sales and consulting services for example), and where systems have been built in multiple organizations to accomplish what amounts to the same function.
Whereas capability modeling describes what the business does, process modeling shows how the business does it. It is an old axiom that businesses are nothing more than collections of processes, and there is a lot of truth to thatstatement.
Where capabilities are hierarchies, processes are flows.Processes have well-defined beginnings and ends. Typically processes start with an event (a customer call starts a service process, or the 10th of the month kicks off a financial reporting process), and they consist of a set of steps (tasks) and branches. Processes end with measurable business results, such as the conclusion of a sale or the manufacture of a product.
Like capabilities, processes can be decorated with useful information, such as who (or what) does a particular step, how long it takes, how much it costs, and so on. You might find, for example, that a given process goes through a time-consuming exception path more often than originally thought – perhaps an automation opportunity.
Six Sigma professionals are usually very well trained in documenting, measuring and optimizing processes, and that is why Six Sigmaorganizations are often closely linked to, or part of, the EA team.
Ideally, the EA team maintains a repository of processes, reflecting the actual operation of the business. Such a repository, if current, and if semantically consistent across the company (does everybody have the same definition of ‘customer’?), can be extremely powerful in providing as-is and to-be analyses as well as impact analysis. BPMN is a proven industry standard for process modeling.
Processes and capabilities provide different, but important perspectives on the organization, how efficiently it runs, and where there are opportunities for improvement, automation and optimization. In future posts I'll have more to say on this topic; I’ll also talk about how strategy maps can be used to prioritize what the organization does, and the critical role of innovation in EA. If you're interested post a comment and that'll help me focus the next posts!