We’re familiar with the enterprise architecture (EA) frameworks such as those of Zachman, TOGAF, and Federal EA Framework (FEAF). These frameworks provide a conceptual structure of ideas (Merriam-Webster, 2014) that helps us understand the process, value, and function behind EA. Is there one among these more popular frameworks that adequately expands on the business architecture value proposition of aligning strategy with tactical demands? Probably not.
What we need is a new business-oriented and customer-centric business architecture framework. Allow me to introduce a set of concepts and principles for this new framework that’s closer to the essence of business architecture. Let’s call this new framework, for lack of a better term the Enterprise Business Architecture Framework (or EBAF).
From my years of teaching EA planning at the graduate level, I found it cumbersome to explain to my graduate students how business architecture is not just about information technology (IT). I can’t blame them. The handy one-page diagrams available today that illustrate business architecture’s role in an organization are those of the more popular EA frameworks. Unfortunately, my students find it difficult not to associate these EA frameworks primarily with IT.
I can see the problem, literally. Let’s take a simple test.
If we happen to walk to the office pantry one day and see a piece of paper on the floor with a sketch of Zachman’s matrix or TOGAF’s process flow, will we think that maybe someone from IT owns it? My guess is that we will. First, we’ll see the words architecture, technology, data, information, process, and so on written on the page. Second, the lines and shapes drawn around these words remind us of geometry back in high school or some diagram in our physics textbook.
We need a better way of illustrating in one page the concept of EA without necessarily sounding and looking like an IT person owns it. We can achieve this by re-inventing our diagram (and the framework it represents) to clearly show that probably somebody from finance, sales, or the office of the CEO owns it. We need it to be business-oriented and customer-centric.
First it has to be business-oriented. It should be about business outcomes. It encapsulates what’s essential in the business model, business context, strategic intent and goals. The focus of EBAF can be the stakeholder segment, value proposition, channel of distribution, and the set of core and supporting business capabilities that operationalize the strategy where strategy can emanate from the top and from down in the trenches. EBAF should be able to capture these and show clear traceability to business outcomes.
Second, this new framework has to be customer-centric. Customer is still king in this day and age. The trend nowadays shows that customer experience is still central to any business model. Examples in the technology-enabled sectors of business include responsive web design or mobile first design, empathy-based business analysis, service design that tracks the customer journey, needs-based approach to systems development, and so on. It’s no secret that small to large organizations sustain profits or expand quality services by simply meeting and anticipating the basic needs of their stakeholders.
What do we leave out in the process of developing this new framework?
We’re getting rid of the technology bias that’s prevalent in current EA frameworks. Technology certainly has a place in EBAF. But it’s no longer the main attraction. Technology plays a supporting role, similar to other enabling capabilities in the organization. Instead, the stakeholder segments, business imperatives, strategic context, metrics and dashboards, organizational culture, business capabilities, business processes, etc. take center stage.
We’re also more focused on the right stuff, namely crafting strategy to meet customer needs. We’re focused less on service levels, interfaces, solutions, and constraints. In the old process, it is not too difficult to lose the point of doing what we’re doing, namely to achieve business outcomes. We lose the line-of-sight between strategies that meet our customer’s needs against our day-today decision-making because EA’s metrics for success are not clearly aligned with business outcomes. And oftentimes productivity suffers because we ineffectively perform according to misplaced measures.
To use an analogy from the performing arts, customers and stakeholders take center stage. Business outcomes set the tone for the dialogue. Business services define the script. Business capabilities form the stage. The organization structure and technology-enabled processes play supporting roles.
Figure 1. Enterprise Business Architecture Framework
How can you differentiate EBAF from the rest of the EA frameworks?
First, it’s dynamic versus static. Most EA frameworks are meant to be used as a reference book, like a dictionary or encyclopedia. Data stored in these repositories seldom change. They were built that way to provide consistent use of terms and establish standards. However, it’s difficult for a business person to act on these concepts especially in the world of business where change is the only constant. There has to be a better way of capturing the shifting priorities of an organization and the resulting feedback in a blueprint of the enterprise.
EBAF allows us to capture the dynamic nature of change as it unfolds. Strategy can emanate from the top or the bottom parts of the organization. Customers and business partners may change their preferences every minute, hour, or day. Products and services develop from within and outside the organization. Employees can move from one group to another and skill sets vary according to the tools required.
Second, it’s actionable versus illustrative. What you see isn’t simply a blueprint of the organization. It’s not something that you can stare at, appreciate its comprehensiveness, and then stow away in the filing cabinet. It actually shows what you can do to make money or save money. Or it can open fruitful discussion on better ways of serving your constituents.
Third, it uses business lingo versus tech-speak. The design principles for EBAF illustrate this. These design principles serve as guideposts to what kind of outcomes we may expect to achieve.
Our first principle is that form follows function. Just look at some of the most beautiful structures man built that still survive today. The Pyramids, the Banawe rice terraces, the tallest buildings in the world, and so on have one characteristic. People built them because of an unmet need. Once built, people actually used them. That’s what a framework should be. It’s there because you need it and you use it because it’s there.
Our second principle is to begin with the end in mind. To who are we supposed to show our diagram? What do we expect them to do about it? When is the right time to show it to them? In what situations merit their existence? In other words, why bother? Executives want quick, actionable insights. How do we deliver these to them using our diagram?
Our third principle is to think out of the box, literally. Let’s design something different from what we’re used to, especially those of us who grew up thinking in technical terms. But relate it to the familiar so that we don’t need a manual to explain how to use it. A box with four sides is a common symbol among the EA frameworks to illustrate a component, layer, or architecture. Why not think of another shape like a circle, which can demonstrate motion as well?
Below is a sample EBAF for a national bank that incorporates most of these design principles. It is not prescriptive or authoritative but only guides the business architect towards a more consistent design process within known constraints.
Figure 2. Sample EBAF for a national bank
In summary, the current business environment where competition is fiercer and customers are more demanding require a new way of illustrating business architecture’s value proposition. Where current EA frameworks fail because of their IT-orientation, the Enterprise Business Architecture Framework fulfills this need for a new business-oriented and customer-centric framework. And there’s no mistaking this time that someone not from IT came up with this brilliant idea.
References:
Merriam-Webster. (2014). Framework.
