EA teams must find ways to generate EBA artifacts and also leverage the business modeling efforts within projects. Doing so positions them to contribute to the high-level decision-making process of a strategic transformation effort driven by the enterprise’s highest levels of leadership.
Many enterprise architecture (EA) groups struggle with affecting change in the ongoing activities and existing project portfolio that demonstrably moves the enterprise toward the future state business strategy. One of the reasons is a lack of understanding of business strategy, process, information, and operations from the perspective of business executives. Some EA groups are beginning to overcome this challenge with the help of an enterprise business architecture effort, with active participation from business professionals.
Many organizations, large and small, public and private sector are consistently faced with many of these problem statements:
- We have information. How can we make better use of it?
- How can our business leverage the cloud?
- What technology capabilities can we better exploit?
- Where do we need more integration between business processes?
- Why is it so hard to connect business processes?
- Where do we need business processes to be the same across our enterprise?
- Who is looking at the whole solution portfolio rather than just individual solutions?
From our perspective, we suggest that the EA program can help with these problems by identifying and then articulating the vision of the future business in a way that both business and IT executives will understand. Further, they not only can identify needed changes in the future, but also potential time- and cost-saving efforts to implement them within the existing project portfolio. A key to being able to do this for the business is the creation of an enterprise business architecture.
Enterprise business architecture (EBA) is gaining a lot of attention in EA programs, at industry conferences, in the press, and even in the boardroom at some progressive, mature companies. We have definitely seen an increase in the number of programs formally developing EBA as part of their overall EA, but those efforts are all over the place in terms of artifacts, methods, process, and participation. At one extreme, there are IT-only efforts, focused on business capabilities and business process modeling. At the other, although rare, there are business executive owned and sponsored efforts focused on making real business transformation occur in a planned fashion.
WHAT IS ENTERPRISE BUSINESS ARCHITECTURE?
Enterprise business architecture is a set of artifacts/methods that help business leaders make decisions about direction and communicate the business changes that need to occur in their enterprise to achieve their vision. The audience for EBA is business leadership, more specifically enterprise-level business leadership—the CEO, president, CXO, board of directors—basically the highest level of management in your enterprise. The purpose for EBA then is twofold:
- Assist the highest level of management in your organizations to make decisions about the future.
- Communicate the changes that need to be made across the organizations to follow those decisions.
The reason that so many organizations have struggled, and will continue to, is that this work is not solely the domain of IT professionals. It requires real business expertise and an executive viewpoint to develop and leverage an EBA effectively. This happens to be the biggest issue for IT-centric EA groups as they try to get started with EBA.
We see three different scenarios under which EBA either gets started or takes another step forward. These are not mutually exclusive.
Scenario 1: The IT-centric EA group develops a set of EBA artifacts, including high level context diagrams of business processes and information flows, relationship matrices to map business process, information entities, and/or business applications to each other. Our experience has shown that involving business professionals in this scenario adds to the quality of these initial deliverables, if they are available to participate. The advantage of this scenario is that these types of artifacts position the EA team to communicate more effectively with business executives when they have a chance to have a discussion at a strategic, transformational level. The disadvantage is that the artifacts will lack credibility and alignment with true business direction until there is more involvement from business executives.
Scenario 2: There is a major implementation effort, such as an ERP, that requires a large presence of business professionals looking at business processes and information in the areas to be supported by the implementation. This effort usually involves some level of business process and information modeling, as well as some application portfolio analysis. If the EA team has previously created the artifacts mentioned in Scenario 1, they can be leveraged here. However, since this is an implementation effort with finite boundaries, scope, schedule, and budget, those deliverables are not usually part of the implementation team’s plan. However, the EA group has a great opportunity to leverage this broadly scoped effort to both create more business-friendly artifacts and linkages between artifacts at different levels of abstraction. Most importantly, though, access to senior executives involved in the high level decision-making processes would allow the EA group to demonstrate that EA can help with the context, impact, and implications of those decisions.
Scenario 3: An enterprise is engaged in a long-term, broadly impacting, strategic transformation of the way that its business is fundamentally operating, such as Smart Grid in an electric utility, e-government, or a major merger/acquisition. This effort is driven by the board of directors, CEO, or highest level of management with an eye on the long-term growth and persistence of the enterprise. These tend to be multi-year, high-dollar investments with far-reaching impact on the way the company will operate, the way it is organized, the information needed, the skills and competencies of the work force, and the business applications and IT infrastructure. In more than one instance, we have seen senior executives proactively involve EA in these types of activities. Executives like that the EA group can speak their language, think long-term, create useful artifacts that simplify the enterprise’s complexity, and also bring domain knowledge of a key enabling area of the company—information technology.
CONCLUSION
Let’s wrap this up with a question that I have been asking most groups I have spoken to in recent years: “As an enterprise architect, are you architecting the enterprise, or are you architecting the IT environment?”
I dare say, most of you (if not all) would answer honestly that you are architecting the IT environment (apps, data, and infrastructure), albeit with a significant alignment with the business of your enterprise. In any case, I suggest that true EA requires both business-owned enterprise business architecture (EBA) and enterprise information architecture (EIA).
The implication of this suggestion is that EBA as thought of in the traditional sense is not within the domain of IT; but rather, it is owned, driven, and primarily developed and maintained by a group of business professionals within the enterprise. Further, there is also a separation of EIA and enterprise data architecture, with EIA in the business domain and data architecture joining application and technology in the IT domain. Figure 1 depicts the relationships described above.
