Business Architecture Enhancing Business Value
By Peter Lutz, Enterprise Architect, Dimension Data
Getting IT to deliver business value is my nutshell definition of Enterprise Architecture. The first part of this is to understand what drives business value and that comes from knowing what the business actually does. I’ve had the enormous privilege learning from amazing mentors and working for outstanding companies across a variety of industries. What I’ve learned is that while there are similar patterns of organization, process, and technology adoption, every enterprise has their own narratives about what drives their value. I’ve found that sneaking in conversations about business architecture has been extremely valuable in understanding those narratives.
“Getting business to tell you what it wants to do” is a nutshell definition of Business Architecture. Here it helps to have an industry specific reference model to start the conversation with familiar terms and concepts. It’s better yet to tie this to a business value chain so that the reference model is easy to understand (fig 1). While IT’s engagement with the business has benefited from the evolution from requirements gathering, to use case development, and to Agile user stories (and beyond), it does not answer the question “is what I’m building of value to the business?” Business architecture can answer that question and you want to get to that question before you start building. One of the answers you will get is that “users” don’t want a different experience with technology from how they use it at home versus how they use it at work.
Figure 1: An indicative industry reference model for Pharma R&D which shows high level business capabilities and how they support specific areas of the business value chain (on top)
One way Business Architecture can help an organization is by just providing a baseline of what it does right now. Capability modeling can be an effective way of doing this, the example I’ve used (fig 2) shows how business capability both contributes to business value and is supported by specific processes, people and services – services here being IT services used by the business. Huge thanks to all the contributors to TOGAF here for developing the underlying framework. Note the capability model is not an organizational model, and in fact when you develop one you may well find gaps and overlaps in your current state. The baseline model should be lightweight, relatively uncontroversial, and fairly accurate. The often-misused adage do not let perfect get in the way of good definitely applies here. Components should be the key constituents and it should be well understood how they contribute to business value.
Business architecture and specifically, capability modeling is a proven way you can map technology to enable specific outcomes and business value
The baseline is just a start. From here you can work with business strategy to define your “to be” state to incorporate new and enhanced business capabilities. Are you doing mergers and acquisitions? Baseline your merger target organization and compare. Are you planning to divest? Understand the dependencies between capabilities so you can still support your value chain once the organizational change is complete. At the very least the baseline is an effective communication tool between multiple stakeholders for ongoing operations.
Figure 2: A simplified and partial example capability model showing capabilities supported by specific processes, people and services (e.g. technology, data, and applications) for the Pharma R&D Project and Portfolio Management capability
Capability models need tenderness, love, and care and there are some principals you will want to apply:
1. Keep it lightweight: It should be an overview of capabilities not a detailed description
2. Use it to drill deeper when necessary: As in oil exploration, drilling is expensive. Only drill into deeper layers of process and systems if doing so adds value to the overall model and where further clarification is required
3. Keep it current: The ecology of the business will change to respond to the market, incorporating capability modeling into ongoing change management is a good way to keep it current
Some organizations overlay financial and data modeling to the baseline capability model. That can provide great value, but at the risk of making the model a bit unwieldy. Ultimately the model will only be successful if it, like technology, is of immediate utility and easy to learn.
Let’s cut short to some typical results:
• Your IT estate supports multiple redundant systems supporting multiple redundant business processes
• Your IT spend is mostly for running commodity services (e.g. email, voice, print, networking)
• Your IT office is often the office of “no” and cites regulatory, security, and current procedures to push back “user” demands
Once you’ve identified the key problems the fun starts with solving them.
Business architecture lets you respond to these results by focusing on business value and making the case for business change to support IT innovation. For example, security is always a concern, but is end-to-end encryption required for all data? Another example, regulations may seem to restrict adoption of new technologies, but do the regulators and your own QA departments know that technology can be implemented to address the actual context of the regulation?
Users have different expectations for different contexts, but the trend will always be for immediate utility and ease of use. Great people and an innovative marketplace are great places to start finding the products and services that drive business value. Business architecture and specifically, capability modeling is a proven way you can map technology to enable specific outcomes and business value.
The need for transforming IT from as business support organization to a business partner has never been greater. If you think that current user demands are excessive, wait till this generation of kids grow up and start working for your company!