As BPM begins to expand beyond isolated projects to mainstream programs at the division or enterprise level, there is a need to engage a far greater number of business people in the...

Surviving the Business Architecture Center of Excellence

I have had the pleasure of leading several Business Architecture Centers of Excellence (CoE). They have not always been called that, however. Centers of excellence have been around for a long time but with regard to Business Architecture they have only been around for a couple of years.

When we formed those centers of excellence we did not have a blueprint or any kind of reference model. What we had was a need to see the big picture of where the business needed to go. We knew the strategy and we understood the goals and objectives. We also had a set of planning and modeling techniques to bring to bear to ensure that the many business and IT initiatives satisfied the business needs. In this article I describe one CoE that I will never forget.

An Afterthought
The Business Architecture CoE was not in the original plan. The original plan included modeling the business processes of multiple business functions and implementing IT solutions to support those business functions. There were so many business and technology initiatives running concurrently that they eventually realized that they needed a Program Office. But they still had not realized that they needed business architecture.

As the technology solutions were rolled out it became clear that they did not meet the needs of the business. Though everyone was trained in each system as it was released, staff could not use the systems for various reasons. In some cases the system just didn’t match the way they did business. Of course, they had not finished defining “how” they did business so everyone conducted it differently. In other cases, departmental solutions were sanctioned simply because they were quick, easy and satisfied an immediate need, not because they satisfied any critical, high-priority objective.

Eventually they figured out that they needed to make decisions based on business value. It was not enough to know that every system was needed; they could not deliver every solution all at once. They needed a way to align the many technology solutions with business need.

Requirements
Let the finger pointing begin. The first complaint was requirements; IT insisted that they did not have good requirements. Isn’t that the way it always is? Bad requirements are the root of all evil?
We knew this distraction would keep them from focusing on the real problem so we solved this problem first. We did not attempt to create perfect requirements before moving on to the bigger issue – alignment. Rather, we introduced a methodology to ensure that IT knew precisely what they were getting for requirements and knew precisely how to move from analysis to design and construction with full traceability.

The difficult part of this first step was rolling out a new methodology in the midst of all the chaos, not to mention the sheer size of the program. They had five teams of business analysts in one state and five corresponding development teams in another state. The CoE had to ensure that all of the analysis was captured in a consistent form and in consistent levels of detail. It then had to ensure that the development teams leveraged all of that good analysis.

This effort, however, did not ensure business and IT alignment. All it assured was that requirements were met. It did not answer any questions about value nor did it take into consideration any business priority for the IT initiatives.

Alignment
Having eliminated the requirements distraction we moved senior leadership’s attention to what they should have focused on before they launched the program – business value. There was no doubt that all five of the core business functions needed process models and IT solutions. However, without having looked at the business value they found themselves wasting resources on what could have been quick wins had they developed a quick-win strategy. These early initiatives provided so little value that they jeopardized the entire program.

We sat down with senior leadership and asked them to review with us the stated objectives; they did actually have stated objectives. Once we gained a good understanding of what they were trying to accomplish we asked them to put priorities on the objectives. As you can imagine there was much heated debate. The executives from each of business functions thought their respective needs were more important than any of the others and that their related initiatives would provide the most value.
We followed the meeting up with a survey. Allegiances were still apparent. However, the survey forced them the give values to all of the objectives; unlike in the meeting where they seemed to think it was all or nothing. This allowed us to put weighting factors on the objectives. Then we aligned each initiative with the objective(s) that it addressed and captured the degree to which it addressed the objective(s). A quick bar chart later made it apparent which initiatives provided the most value.

Program Management
The Program Management Office (PMO) did more for this program than consolidate work plans, report status, and manage risks and issues; I have been on some that did more and some that did less. By virtue of the consolidated work plans the PMO knew all of the dependencies. In too many cases, however, the PMO does not know that there is a slippage until after one of the projects misses a milestone. The PMO on this occasion was given the added responsibility of measuring the methodology, which made meeting or missing milestones more predictable.

The PMO also became involved in decisions to change the program. When executive management sensed a need to reevaluate objectives, the PMO could tell them what affect a change in the portfolio of initiative would have, both in terms of cost and value.

Conclusion
The CoE in this case was spread very thin; centers of excellence are never staffed with a large number of resources. The resources that are assigned to the CoE are assigned based on need, change over time, and must have both business sense and technical comprehension.

In this case we were rescuing an extremely large program in trouble. Senior leadership knew what they needed but was either distracted by the latest, hottest fires or focused solely on whichever project was costing the most. And in those cases where the project that was costing the most happened to also provide the most value, they still took their eyes off the big picture and focused too much on the minutia of the initiative.

So despite having to split our time between ten teams and two states and despite having to pull senior leadership out of the day-to-day management to focus more on setting direction, we survived this CoE. But I would like to encourage everyone reading this article to think about business architecture as forethought, not an afterthought. Not because senior leadership does not know what they need or that IT can not deliver projects effectively but because the CoE’s job is to ensure alignment so that senior leadership can focus on leading and IT can focus on delivering solutions.

Mr. Balmes is a Senior Business Architect and Management Consultant with a natural talent for improving business effectiveness by integrating Business Architecture into the enterprise and leveraging the latest trends in Business Process Management and Services-Oriented Architecture. He employs expert skills from more than 25 years of domestic and international experience with well-studied, proven approaches for evaluating business effectiveness and ensuring alignment between IT and the business.
Mr. Balmes can be reached at gbalmes[at]collaborativeconsulting.com, or, visit the Collaborative Consulting web site at www.collaborativeconsulting.com.

Back to Articles, including BPM, SOA, BDM, BA & OP