Business Architecture is not an intuitively obvious concept. It does not conjure up an immediate vision of what it is, or what it comprises. With this inherent disadvantage – the business can’t articulate it easily – how can it be used to align IT with the business?
Business Architecture includes three components: the Functional Architecture, the Process Architecture and the Information Architecture. There are well documented methodologies for developing each component. The question becomes “Where do you begin, and what do you with it once you have it?” When these are answered, determining how to leverage the Business Architecture to align IT with the business becomes clearer.
Business Architecture: Where to Begin?
The Functional Architecture is a critical first step in developing the Business Architecture. Though it is not the most complex component of the Business Architecture (in fact, it is a rather small step), it is important to segment it properly so that the next step, the Process Architecture, focuses on the customer and revenue generation.
Begin by segregating business functions into strategic, core and support functions. Strategic functions deal primarily with vision and strategy, and result in identification of desired markets, customers, products, and services. Support functions like Finance, IT and HR support core business functions, which focus on the customer and revenue generation. But it is not that easy; the core business functions must be further segregated.
Break the core business functions down into customer-facing, internal and “network” management layers. For example, Claims Administration is not a single core business function. It has a customer-facing component – Claims Submission – whereby the business supports customers’ efforts to submit claims. It has an internal business management component – Claims Processing – whereby claims are actually paid/denied. And, it has a “network” component – Claims Administration – whereby the business makes organizational decisions regarding the efficiency of claims processing and the effectiveness of customer support.
Having segregated the core business functions, define them enough to understand the scope of each. This should not be a labor-intensive exercise; typically a paragraph will suffice. From here, two paths are initiated: perform an Application Rationalization, to ensure the right mix of applications is in place, and launch the Process Architecture.
Process Architecture: Directing the Technical Architecture
Developing the Process Architecture is not an all-or-nothing endeavor. To treat it as such risks developing and managing processes for the sake of developing and managing processes. There is little potential to realize true value.
Having isolated and segregated the core business functions, let business priorities and pain points dictate functions that should be articulated further. If the customer experience has the highest business priority, the focus should be on customer-facing business functions. Or should it?
Continuing with the Claims Administration example, by all means, work to improve business processes that involve the customers and their claims. These include submitting a claim, checking on its status and even questioning its disposition. However, we cannot stop there. If the Claims Administration business function makes an organizational decision influencing the effectiveness of supporting claims submission, we must also review business processes in the “network” management layer.
There are any number of methods to grade a set of process initiatives based on business priorities. Some are more scientific than others. Pick one that fits the environment, apply it consistently, and use it to achieve consensus between the business community and IT. However, depending on the organization, this step could be more difficult than it sounds.
Once this is complete, it is finally time to start developing the Process Architecture. There are industry standard techniques to document chosen processes. The particular technique, however, is not as important as the outcome. If the Process Architecture will tell the Application Architecture what data to pass between applications and when, the process models must include sufficient detail regarding information flow. If the Process Architecture is to ensure that every person or organization involved effectively executes against the process, the models must fully document their respective involvement in the process. Too often, process models that describe the process very well fail to demonstrate information flow effectively. In addition, they rarely document the involvement of people and organizations suitably (even with swim lanes). Ensure that the Process Architecture effectively answers questions about the people, process and information aspects of the business.
BPMS: Leveraging Services
A CIO recently expressed an interest in a BPM strategy by asking “How can I get the business to use these services we’ve developed?” I told him he was asking the wrong question. He should have asked “How do I know what services the business needs?”
The Business Architecture is how you know. It indicates precisely how many processes are shared, what information is shared and where the common processes fit in the end-to-end value chain. Simply, it shows which services will provide the most value to the business.
The first step for IT is to rationalize the Application Architecture against the Functional Architecture. That will tell IT if it has the right mix of applications to support the business with minimal redundancy, and cost. While rationalization is underway, the Process Architecture and the Information Architecture are developed.
Using the Process Architecture to identify where common services will benefit the business is the second step. Of course, most IT organizations considering a Service Oriented Architecture (SOA) do not wait for a Process Architecture. They already have an Integration Architecture, which may or may not include an ESB, and they already have services developed. However, just because IT did not wait for a Process Architecture to move forward with Services does not mean the effort was wasted. At the very least, IT has an excellent prototype. At best, IT knows enough about the business to have developed valuable services for it. Either way, the work was worthwhile.
The third step is to implement a Business Process Management Suite (BPMS) to assemble business processes that enhance operational efficiency. IT must implement the technology and work hand-in-hand with the business to ensure it leverages the technology optimally. IT must also provide the governance. If not, it is simply providing a new technology to perpetuate silos, rather than using the new technology to break them down. Also, by working closely with the business, IT gains first-hand experience with the services that benefit it most. This begins the continuous cycle of improvement: the BPMS leverages the services and monitors the business processes, the business improves the processes, and IT improves the suite of services.
The final step remains formal Organizational Change Management. Remember, defining change is not enough. Never overlook the value in sharing the vision for change, creating incentives for it, supporting it, and crafting a program that ensures that every constituency is considered. When embarking on a cycle of continuous improvement (i.e., change) it is important not to exceed the organization’s capacity to change.
