Understanding EBA - Part 3

Discussion for EA874 Topic 6 > Emerging Business Architecture
Post # 3

We have seen how our discussions of business architecture highlight the primary task of "architecting the business" via a transformational road map, which essentially keeps the business strategies formulated at the highest executive levels closely in mind, as EA clarifies the IT solutions which help develop the business capabilities of the organization, in order to bring value to its customers and enable competitive advantage.

A business capability is what an organization needs to be able to execute its business strategy.  And as such, the organization may identify the need for a number of capabilities as part of its strategies. To do so, a capability must thus be a collection of people, process, and technology --  all of which are needed to address a specific purpose or goal.  To manage and prioritize capability identification and development, the organization will need to review its customer value proposition in order to establish performance goals for capabilities. Ultimately, the organization should focus on those key capabilities that bring efficiencies in costs and operations, innovation and growth.

An organizational capability will need to refer to the way its people and systems work together. Organizations are said to have capabilities, while its individual members are said to have the competencies. Combining all of these together, it is said that the resulting company's culture is defined by how management fosters talent, mindsets, and collaboration as it strengthens competencies. Moreover, social and technical competencies on one side, and organizational capabilities on the other, will work together and can intersect in different ways. As business architecture provides key inputs towards the tranformational EA road map, effective change management will make sure to consider culture and competencies with capability development.

Alongside business capability, what we study and call "process"  is that which describes how the capability is executed. There is thus a basic difference between business capabilities and business processes. Business capability is “what” the business can do in order to reach its goals and objectives, while the business process  is “how” the business is making use of its competencies to do things, or what actions are taking place in order to promote and execute those capabilities. Much of the business reengineering hype of the previous decades, or the so-called business process reengineering activities, focused on how to redesign business processes to achieve higher efficiencies and operational effectiveness.

There is no doubt that the architecture community is familiar with using different notations for describing business processes -- e.g. known standards such as BPMN and its versions, as well as the BPEL, UML, IDEF models.  On the other hand, capability modeling is a less familiar activity. Not surprisingly, capability modeling is more difficult to deal with, because capabilities are more abstract notions, and grasping such takes more time and effort. However, understanding capabilities is a critical success factor for the organization, as it brings an important advantage, since the "what is needed" or capability of the business is part of the strategy.  Lastly, it is useful to note that a capability is logically a more permanent fixture and theme in the organization's guiding horizon, and is seldom changed, characterized as long-term.  In contrast, the "how" of a business process can be quite dynamic, and adaptive to the emerging tools --  and therefore has the tendency to change, and can be changed a lot.

Finally, what we call the "solution architecture" is the framework with which EA delivers a needed capability to the business, where the delivered capability consists of process, information and technology components. Solutions maintain their integrity and coherence within the framework by adhering to the principles, standards and guidelines captured in the Enterprise Architecture,  perhaps with ESA-level guidance such as solution patterns, to ensure that individual solution architectures remain consistent to the EA at large.


Conclusion:

The way an organization's people and systems work together, combining to form the  organization's culture, defines how management fosters talent, mindsets, and collaboration. Together, these factors enable the organization to develop capabilities which are essential to the organization, as well as those which address specific business necessities, strategic support, and key differentiators in its customer value proposition which create advantage.

As we continue to find ways of showing value for business architecture --  perhaps with better definitions for its methodological framework, we need to learn mastery of mapping out capability development, to enable and promote the organization's pursuit of the so-called "digital business". By doing so, business architects can help the organization better understand the impact of technology on business value, and help the IT organization better understand how to  develop tools and frameworks that business can use to unleash competitive advantage for the organization.

/

Understanding EBA - Part 2

Discussion for EA874 Topic 6 > Emerging Business Architecture
Post # 2

To continue our pursuit of clarity and resolving confusions, we come to the next area of ambiguity: that of Business Architecture and Business Analysis.

I make heavy use of Nick Malik's discussions on this post, and will try to relate them with the previous discussion of Business Context vs Business Architecture. I hope that sharing Nick's post can move us closer to more clarity.

Nick came up with his own definitions below, which I think is useful, and builds on the notion of capability in our discussions.

Business Architect – A role within various types of enterprises (business, government, non-profit) that is focused on collecting information on the strategic positioning of an area of activity (line of business, business unit, department, team, etc.) and creating a clear picture of the capability gaps that may impede that area from reaching it’s full and required potential.

Business Analyst – A role either within an information technology division of an enterprise, or within a non-IT team serving as a key point of contact with an IT division.  This role is focused on understanding the root cause of a specific business problem in order to develop the IT requirements needed to address that problem.

The following is Nick's separation of job descriptions and expectations, which can add to fine-tuning our way of defining the inter-related tasks of the so-called Business Architecture discipline.

The Business Analysis Body of Knowledge (BABoK version 2) specifically states:
“A business analyst is any person who performs business analysis activities, no matter what their job title or organizational role may be. Business analysis practitioners include not only people with the job title of business analyst, but may also include business systems analysts, systems analysts, requirements engineers, process analysts, product managers, product owners, enterprise analysts, business architects, management consultants, or any other person who performs the tasks described in the BABOK Guide, including those who also perform related disciplines such as project management, software development, quality assurance, and interaction design.”

Summary:

There are indeed many attempts to define boundaries and distinctions for the business architect and business analyst roles. However, going back to our discussion in the previous post, we again see why there can be a confusion on these roles. If we agree that by virtue of the deliverables of the areas of business context and business architecture being so closely related, we can also agree that we can just easily map the job descriptions and task expectations for the business architect and business analyst, without being too fussy about which role these tasks are placed.

No wonder that there are many organizations who ignore the difference, because it's really just one tightly related set of tasks, that there's not that much to be gained by spending time fiddling with semantics. We can perhaps even think of the business architect as an expanded role of the business analyst. Let's just define the tasks for such an expanded role and move on.

In the end, as Nick Malik keenly points out, the Business Analyst and Business Architect are really best taken as complementary roles. "Regardless of what we want to happen, reality is going to keep getting in the way.  Both roles exist.  Sometimes they intersect."  And while Nick speaks of a "real challenge" from when two people have to play complementary roles, as in this case of business architect, and business analyst, I really see no big issues as long as the complete and distinct set of expected deliverables and artifacts are well-defined and corresponds to our notions of outputs for defining business context, and business architecture. After all, intuitively, all of these activities that we speak of really fall under the big umbrella of the critical thinking exercise called analysis of the business.

/

References:

Nick Malik. (2012 April 6). The difference between business architect and business analyst. Online Blog. Retrieved from https://blogs.msdn.microsoft.com/nickmalik/2012/04/06/the-difference-between-business-architect-and-business-analyst

/

Understanding EBA - Part 1

Discussion for EA874 Topic 6 > Emerging Business Architecture
Post # 1

Enterprise Architecture if it wants to live up to its primary purpose of aligning business strategy with IT directions, would need to be cognizant of both areas of business and IT - not only clear on what IT thinks and want to do, but also clear on what big things business wants to achieve and how to get there.

There has been an on-going debate on whether the domain of Business Architecture is really part of EA's business, and I would think that based on our class directions and discussions, we think that it should, i.e. there should be a significant part of the EA discipline whose primary focus is clarifying the business side for the other technology domains to understand and connect.

As far back as 2010, there were EA circles who believe that Business Architecture is something different from enterprise architecture. Gartner's Philip Allega has described this to be a blatant attempt to classify EA as something only applicable to IT,  and argued that, in fact, EA is applicable to the the whole enterprise that covers numerous viewpoints for stakeholders, including business, information, technology and solution architecture. I would think that indeed, this is an early old school perception of enterprise architecture, during those times that the EA discpline tries to reach out to make the business connection coming from the IT camp. Today, we know that to effectively align IT strategies clearly with the business mission, EA must have a strong holistic view from both business and technology sides if it wants to present a meaningful and integrated enterprise architecture that can truly bring value to the organization.

To pursue EBA clarification, Allega first reviews and sums up Business Context, arguing that context is composed as follows:

1. A vision of the future state.  Gartner calls this the Common Requirements Vision.  This deliverable is typically 10-12 pages and explicitly connects environmental trends, business strategies and requirements of business process and IT together in priority matrices.  This is a conceptual level document that requires confirmation of the target state, and its associated priorities, by the top of the governance decision-makers – typically, the people who decide how to allocate resources in the organization.

2. A root, anchor model. The highest visualization of the enterprise, recognizable to the business, may be in the form of a business operating model, a hyper-extended view of the business ecosystem, business capability maps, a federated model or some combination of these for particular stakeholders.  All business processes, information, applications, solutions, technologies, people skills, people, other entities, are overlaid upon and disaggregated from this root, anchor, model.

3. A set of guiding principles. These shape the investment and action behaviors of all those who seek to select, create, and implement anything within any EA viewpoint.


The earlier Gartner article of Burke, Allega, and Lapkin (2009) offers a key diagram to show that it is the business context that feeds the EBA viewpoint, and not the other way around.

EBA artifacts is said to describe the aspects of the business ("how we do business") and describe how these aspects must change or evolve to reach the overall EA future state. Gartner defines EBA as: That part of the enterprise architecture process that describes — through a set of requirements, principles and models — the future state, current state and guidance necessary to flexibly evolve and optimize business dimensions (people, process, financial resources and organization) to achieve effective enterprise change.

Thus "business context" is focused on articulating the business strategy; environmental trends (including internal, external and macrotechnology trends); and requirements to ensure an effective strategic alignment with business and a focused direction of effort. On the other hand, Enterprise business architecture (EBA) is focused on producing the business dimension in order to "architect the business."

"Architecting the business" is that significant amount of work supported and addressed by the EBA discipline,  the impact of which benefits the organization by having the clear understanding of the ripple effect of these business dimensions with regard to the rest of the enterprise architecture. As such, this makes Enterprise Business Architecture that particular discipline that provides the road maps needed to effectively manage business transformation, turmoil and evolution.

Summary:

I think most of the confusion comes from the boundaries that the current literature place on business context and business architecture. While most of the Gartner discussions advise the separation of business context and business architecture as shown above,  I think it comes intuitively that these two areas of work are really closely related, and it is not surprising that they are usually thought of one and the same, or at least tightly inter-related areas of concern that feed each other to make it seem like it is one and the same contiguous set of concerns -- for all practical intents and purposes.

Does it really damage our EA schema if we combine these areas?  I don't think so, as long as we know that there are business context deliverables and there are EBA deliverables, we can just really make sure to take care of these two critical areas, and label them as part of the Business Architecture discipline. No harm done. At least I don't really see any, and simply shifting the label actually removes a lot of confusion.

/

References:

Philip Allega. (2010 August 30). Business Architecture is Part of Enterprise Architecture. Retrieved from http://blogs.gartner.com/philip-allega/2010/08/30/business-architecture-is-part-of-enterprise-architecture/

Betsy Burton, Philip Allega, Anne Lapkin. (2009 November 13).'Business Context' and 'Business Architecture'Are Not the Same. Research paper. Gartner. ID G00170922.
/