March 21, 2011

Business Services

Posted by Zahavi under Business Services | Tags: , |
Leave a Comment 

There is a lot of discussion today regarding Service Oriented Architectures.  With SOA, systems are designed to expose services so that other clients/applications can consume them.  The resulting system is loosely coupled and the services can be distributed to produce a more flexible system.  

Typically when people talk about SOA and services they are discussing the technical services – the interfaces such as web services that provide access to a particular function.    Examples of such functions include checking an account balance online or using a remote graphics service to create a bar chart given a set of data.

But what about Business Services?  What are they and are they part of SOA?  How do they relate to technical services?  A business service describes something of value that an organization provides its customers, or something that it uses from another organization to provide its own services.   

Business services are at a higher layer than technical services within a SOA architecture.  A business service can be provided by a person or people, by technology, or most often by people who use technology.  When technology is used, there could be several software services that support a single business service.

There is often confusion between the terms capability and service.  If you search on the Internet you will find that there are many views about these two terms and their relationship.  I like the view that describes the service as providing access and the means to use a capability.  Two hospitals may have the ability to perform surgeries, but only one may have the ability to perform Liver Transplants. The service, Liver Transplant, delivers the effect of using capabilities, where the capabilities are made of the organization’s skills (Liver Surgeons, Hepatology Specialty, etc.) and tools (Surgical Suite, CT scans, Ultrasound, etc.) that enable the service. 

My company recently performed a business architecture engagement for a new cancer center.  The work involved understanding how several oncology departments work independently and how they will work together using a multidisciplinary approach in the new center.  We captured a business motivation model, organization models and process models, for the as-is and the to-be states.  We created an accompanying strategy simulation for cancer center planning.  These models are discussed in greater detail in the Business Modeling book.

In addition, we created a business service model as it relates to organizations and locations. This model was not covered in the Business Modeling book and our intent on the project was to understand what services are provided by each department and at which location, and to identify the dependencies on other services.  Then we worked with the departments collectively to determine what services will be provided at the new center, what are the service overlaps, and what gaps exist if the services they depend on are not offered there or nearby.  For example, if in order to provide certain pre-op or post-op services there are dependencies on a phlebotomy service there are three choices, offer phlebotomy service at the center, provide transportation for patients to another location, or change a process so that blood work must occur before or after the appointment.

We have produced a complete business service architecture for a cancer center offering.  We created a classification framework that also identifies each service as billable or non-billable, as mission or non-mission critical, as core to the business, or context – one that is not a core capability and could be outsourced.  This allows for the creation of service groupings so that an organization can determine which services are an important part of its business where investment is warranted, and which services are not as critical and could be outsourced.

We found the business services to be one of the most useful business architecture artifacts as it provided insight into how an organization views its business and helped identify critical gaps.   The resulting architecture serves as a baseline so that other cancer centers that are undergoing transformation can be compared to ensure proper coverage of issues and analysis.

 

December 22, 2008

Business Architecture

Posted by Zahavi under Explaining | Tags: |
Leave a Comment 

What is business architecture? Given recent discussions at the OMG business architecture working group it seems there isn’t quite a consensus on the definition as yet. Some think there is overlap between business architecture and enterprise architecture. A business architecture can be part of an enterprise architecture, but many enterprise architectures focus on technology and only recently organizations have begun to look at enterprise level and cross business-unit business architectures.

Some think that a business architecture is about how the business is performed, its business model and structure. For example, whether a chain of restaurants is company owned or franchise owned.

Some think it is a description of how the various specific business models relate to each other. They believe the various models, such as business process models and business motivation models comprise components or layers of an overall business architecture. Some think it is a list of the specific standards themselves. Standards such as the Business Motivation Model (BMM) and Business Process Modeling Notation (BPMN.)

We named our book business modeling instead of business architecture specifically because of this confusion. The word architecture itself is often perceived to be technical by business people and does not resonate with them. But the term will be used by others so it is important to understand how it fits.

I think the purpose of a business architecture is somewhat analogous to a technical architecture. A technical architecture describes how a solution or system behaves and how it is structured. Specific architectural frameworks (such as TOGAF) describe how to organize an architecture (such as its layers and views) and which standards are applicable.

Similarly, a business architecture should capture how the business behaves and how it is structured. This information is captured using various business models but a set of business architectural frameworks should be the ones that define how particular models relate to each other, what their touch points are, and what standards might be used as part of the architecture. The OMG could produce such an architectural framework to support the creation of business architectures.

For example, the OMG has tried several times in the past to define an organizational structure or organization modeling standard. Such a model seems to be a basic model that is needed in business modeling and we describe it in our book as a separate modeling discipline. Yet, OMG has not been able to standardize an organization modeling standard on its own. Several other OMG business standards reference or require some form of an organization model. Should the definition of an organization be defined as part of those standards? If we do that how will we ensure that there is consistency and alignment between all of those definitions of an organization? This should be the purpose of the business architecture framework, to ensure such alignment occurs.

In the March 2009 OMG meeting in Washington D.C., the business architecture working group will attempt to reach a consensus on the definition of a business architecture and on its components. The group decided to start by identifying the overall categories that make up a business architecture and then drill down into the specific sub-components and standards that support them.

This is exactly the approach that we took in describing, what we called, the modeling disciplines. We named four: the business motivation models, the business process models, the business organization models, and the business rule models. With these as a starting point, it is much easier to identify the relationship between the various models and the applicable standards that support them. Once an architecture framework is created that identifies the components and modeling standards that support them, it will be possible to create business architectures based on the framework.