Are Business Process Management and Business Architecture a perfect match?

Whenever I suggest collaboration between these two worlds, I always observe some sort of astonishment from my interlocutors. Many Enterprise Architects or Business Architects do not realise there may be synergies. Business Process Management (BPM) team have not understood what Enterprise Architecture is all about and the other way around.... There is no a single definition of Business Process Management, often it means different things to different people. To keep it very generic, BPM relates to any activities an organization does to support its process efforts.


There are many activities which can be included in such efforts:
· The use of industry Business Reference Model (or Business Process Reference Model), a reference for the operational activities of an organization, a framework facilitating a functional Lines of Business, such as

o The Federal Enterprise Architecture Business Reference Model of the US Federal Government
o The DoD Business Reference Model
o The Open Group Exploration and Mining Business Reference Model (https://www.opengroup.org/emmmv/uploads/40/22706/Getting_started_with_the_EM_Business_Model_v_01.00.pdf)
o Frameworx (eTOM) for Telco companies
o The Supply Chain Operations Reference (SCOR®) model
o The SAP R/3 Reference Model
o The Oracle Business Models : Oracle Industry Reference Model for Banking, (IRM), Oracle Retail Reference Model
o And others...

· The use of organization specific Business Reference models
· The use of Business process improvement methodologies

o Lean, a quantitative data driven methodology based on statistics, process understanding and process control
o Six Sigma, a methodology that mainly focuses on eliminating bad products or services to clients by using statistical evaluation

· Business Process Reengineering, which in reality is a facet of BPM
· The understanding of Business Change Management, the process that empowers staff to accept changes that will improve performance and productivity
· The understanding of Business Transformation, the continuous process, essential to any organization in implementing its business strategy and achieving its vision
· The use of Business Rules Management which enables organizations to manage business rules for decision automation
· The understanding of Business Process Outsourcing (BPO) services to reduce costs and increase efficiency
· The support of Business Process modeling and design, which is illustrated description of business processes, usually created with flow diagrams. The model contains the relationship between activities, processes, sub-processes and information, as well as roles, the organization and resources. This can done with many notations such as flow chart, functional flow block diagram, control flow diagram, Gantt chart, PERT diagram, IDEF, and nowadays with the standard de facto notations such as UML and BPMN
· The support of BPM tools and suites implementation. With the right, process models can be simulated, to drive workflow or BPMS systems, and can be used as the basis for an automated process monitoring system (BAM)
· The support of Business Activity Monitoring (BAM), the ability to have end-to-end visibility and control over all parts of a process or transaction that spans multiple applications and people in one or even more companies.

To combine Business Process Management and Enterprise Architecture for better business outcomes is definitely the way forward, where BPM provides the business context, understanding, and- metrics, and Enterprise Architecture provides the discipline to translate business vision and strategy into architectural changes. Both are needed for sustainable continuous improvement. When referring to Enterprise Architecture, we would mainly refer to Business Architecture. Business Architecture involves more than just the structure of business processes. It also entails the organization of departments, roles, documents, assets, and all other process-related information.

Business Architects may be defining and implementing the Business Process framework and, in parallel, influencing the strategic direction for Business Process Management and improvement methodologies (e.g. Lean, Six Sigma). The business process owners and Business Analysts are working within their guidelines at multiple levels throughout the organizations’ business process. They have roles and responsibilities to manage, monitor and control their processes.
An important tool in developing Business Architecture is a Business Reference Model. These types of models are enormously beneficial. They can be developed in the organization to build and extend the information architecture. The shared vocabulary (verbal and visual) that emerges from these efforts promotes clear and effective communication.

To illustrate the touch points between Enterprise Architecture and Business Process Management, I have illustrated in the table below the synergies between the two approaches using TOGAF® 9.



In this table, we observe that, there is a perfect match between Business Process Management and the use of an Enterprise Architecture framework such as TOGAF. BPM is often project based and the Business Architect (or Enterprise Architect) may be responsible for identifying cross-project and cross-process capabilities. It can be considered as being the backbone of an Enterprise Architecture program. We can also add to this, that Service Oriented Architecture is the core operational or transactional capability while BPM does the coordination and integration into business processes.

When using BPM tools and suites, you should also consider the following functionalities: workflow, enterprise application integration, content management and business activity monitoring. These four components are traditionally provided by vendors as separate applications which are merged through BPM into a single application with high levels of integration. The implementation of a BPM solution should theoretically eliminate the maintenance and support cost of these four applications resulting in reducing the total cost of ownership.

Business Architecture provides the governance, alignment and transformational context for BPM across business units and silos. Enterprise Architects, Business Architects, Business Analysts should work together with BPM teams, when approaching the topic of Business Process Management. BPM efforts need structures and appropriate methodologies. It needs a structure to guide efforts at different levels of abstraction (separating “the what“ (the hierarchical structure of business functions) from “the how” (how the desired results are achieved), a documented approach and structure to navigate among the business processes of the organization, i.e. a Business Architecture. They also need a methodology such as an Enterprise Architecture framework to retain and leverage what they have learned about managing and conducting BPM projects.

Business Architecture may help to get ISO 9001:2000 certification

The ISO standard is related to the definition and requirements of a quality management system. It helps an organization to operate with increased effectiveness, consistency and customer satisfaction and have the capability to continually improve the management system.

ISO 9001:2000 is based on eight Quality Management Principles which are comprehensive and fundamental rules of belief, for leading and operating an organization, aimed at continually improving performance over the long term, by focusing on customers, while addressing the needs of all stakeholders.

Principle 4 is referring to a “Process Approach”. The standard promotes the adoption of a process approach when developing, implementing and improving the effectiveness of the quality management system. A desired result is achieved more efficiently when activities and related resources are managed as a process.

Product realization is a system of processes by which inputs, such as raw materials or components from suppliers, are transformed through the activities of the organization, such as value added production or assembly operations, into outputs, such as products or components, which meet the needs and requirements of a customer.

Any activity or operation that receives inputs and converts them into outputs can be considered as a process. Almost all activities and operations involved in making a product or providing a service are processes.

When an Enterprise Architecture Committee receives suggestions for strategic changes, they should immediately translate those changes into changes in specific business processes. If the architecture is well-defined, changes in processes will immediately suggest changes in specific applications and databases. There are many definitions of a Business Architecture but they all refer to the definition of processes.

The business architecture is a formal documentation of the lines of business, their support functions and their relationship to each other. After the architecture has been documented, it is systematically analyzed to examine the functions (services) required by business and to align the enterprise technology with those functions.

Companies which have already documented their business architecture (baseline/as-is) may consider to have achieved a great step getting the ISO 9001:2000 certification.

Efficient Enterprise Architecture needs waiver requests...

A waiver request can be a new document type in an Enterprise Architecture program. The purpose of such a document is to request an exception to an approved Enterprise Architecture for information systems and applications. It allows to document the business justification, risk management process, and costs associated with an exception. This document and the associated exception process could apply to any system, application, element, or practice that varies from the approved Enterprise Architecture. These include but are not limited to data, applications, security, integration, collaboration, systems management, network and telecommunications systems, components, practices, and protocols. An Enterprise Architecture Review Board which is the decision authority for all waiver requests and could use its discretion to classify all waiver requests in different categories and will formulate a recommendation for approval or disapproval.

Examples of an important exception request could be:
· The total remediation cost for the exception exceeds fifteen percent of the project value.
· The total remediation cost exceeds USD 0.5 million.
· The exception will introduce a service, product, technology, or practice not currently in use in the company or is categorized as "Emerging" in the architecture.
· The exception violates an Enterprise Architecture principle.
· The exception is a service, product, technology, or practice, which is identified for "Containment" or "Retirement" in the current Enterprise Architecture.
· The exception does not comply with the infromation standards for a system for which it creates, updates, or deletes data.

Whether the waiver request is for a minor or major change, The board domain expert stakeholder or the board team will use the same decision criteria when approving or disapproving a request. Specifically, the individual member or board must determine whether the benefits associated with implementing the exception request outweigh any negative impacts to the IT community. In exercising this discretion, the decision-makers will consider:

· the impact of not granting the exception
· the technical merit of the exception
· the collateral impact to other systems and business processes
· the impact to the Enterprise Architecture
· alternatives to granting the exception
· precedent setting effects

Decision-makers must consider the Enterprise Architecture principles (including Business principles, Information principles, Application principles, Technology principles).

The decision-makers may approve or disapprove all or a portion of a request, based on the complexity of the system for which the exception is requested. The board should develop a consensus in reaching its decision.

The requestor has several important responsibilities in the architecture waiver process. First, the requestor is responsible for documenting the information contained in this form. This information outlines the justification for the exception and is critical to the decision-making process. Second, the requestor is responsible for obtaining the approval of the business owner and the technical owner. Finally, the requestor may have an opportunity to present the exception request to the decision authority on a scheduled basis.

The technical owner must approve all exception requests proposed by the requestor prior to review. The technical owner is the individual responsible for supporting the impacted business process with information systems solutions.

The business owner must approve all exception requests proposed by the requestor prior to review. The business owner is an individual at the director level or above who manages the business process that the system supports or will support.

Business Processes and Services are not always correctly associated

For a few months, discussion around processes and services has been a hot topic in my company. Everybody has his own interpretation and very few information exist related to the subject.

This post is the follow up to a previous article I wrote a while ago:

What is a Service?

It is important to specify that sometimes when people talk, the term Service has to be considered either as an ITSM Service or an SOA Service-web service. This is clear to me that BPM and SOA should be tightly integrated, but let’s look at this slightly differently…

A Business Process has activities. An activity could be one to many Services.

But you can also look at this in another way...

A Service is one to many Business Processes. A Business Process has activities, and as already said, an activity is one to many Services. Isn’t this confusing?

What I try to say is that we need to be clear (at least for me...) when we talk of a Service. Are we talking of Service in Service Management terms, or in SOA Terms?

As an example:

The Service "e-mail" has several Business Processes such has:

Creation of email, classification, forwarding, etc...
Calendar Management, invitation for meetings, reminders, etc..
etc..

If for example we define the Calandar Management process and look at activities, maybe at some stage we would define a Service which lookup for availability of people in a meeting. This would be an SOA Service "Availability of people"...

To summarize and be clear, I would claim that ITSM Services could count one to many Business Processes, and Business Processes could one to many SOA Services. “E-mail” is an ITSM Service and “creation of an email” being a transaction is an SOA Service.

Does this make sense?

"The CMDB Initiative..”, but where is the evolution?

Late April, a group of system and service management vendors decided to propose a standard related to a repository for IT assets, and their configurations items change over time.

In other words, BMC, Fujitsu, IBM and HP decided to create a model for a CMDB which would allow storing information such as desktop and laptop client images or configurations, servers, storage pools or networks and so on.

Very often information is spread among various sources and no standards exist on how to exchange meta data from all these potential sources of CMDB information. Today, the CMDB interfaces that exist are all proprietary, which is the problem that this group wants to tackle.
This working group will issue a white paper within the next month that will spell out their initial goals in more detail. And by the end of the year, they hope to have a draft specification proposal, at which point they hope to formalize the process by choosing a standards body.

But is that enough?

Focusing on data exchange is fine but shouldn’t they also consider the CMDB Meta data and propose a common model eventually re-usable by third parties?

All vendors’ CMDB have their own Meta model and as from now I have never seen from any vendor a roadmap related to the repository. As an example, with the acquisition of both Mercury and Peregrine, HP initially announced the migration from the HP Openview Service Desk, to Service Center, and now has announced that next CMDB would be the one from Mercury, which is in fact…Appilog… (An acquisition from Mercury). So what!

There is a need for a “next generation CMDB” for the following reasons:

- BPM based on a SOA architecture invoque IT components (software on hardware…) and we should have a link between a Business Process and the underlying Cis. A CMDB should also be process based.
- Relation is important that’s for sure but dependencies is another key topic. How does infratructure relates one to the other, how information relates one to the other, how physically components relates one to the other, how does application code relates (Cendura acquired by CA is maybe one of the only company which deleivred that capability) etc… A CMDB should be also able to add dependencies on the top of relationships.

This initiative will help the concept of federated CMDB and information exchange but will not really look at today’s requirements… A unified Meta model could be an interesting initiative for these vendors as this would create a new generation of unified Service management/Business Process management solutions.

IT Processes, Business Processes, who is coordinating what?

More and more IT departments refer to IT Governance, Best Practices, quality and processes. To run efficiently an IT shops, processes are supposed to help companies to excel. The disctinction between best practices and processes is not so clear but let’s assume that this is complimentary. Processes are either standardized; refer to existing frameworks such as ITIL, Six Sigma, eTOM and other best practices.

An IT Process is also a Business Process. It has only an “IT Flavour”.

Looking at the Business side, Business Process Reegineering (BPR) and now Business Process Management (BPM) are activities which also look at improving how a Business works. Some companies develop a target Business Architecture describing the product and/or service strategy, and the organizational, functional, process, event, information, and geographic aspects of the business environment.

Very often, based on my experience, and observations, IT processes do not have a process owner. If there are owners, sometimes they are siloed. As an example, the ITIL Incident Management process owner does not work in harmony with the ITIL Availability Management process owner, etc. Sometimes, politics, company’s mindset, or personnel agendas, prevent to do a consistent job.

On the Business side, it happens also that processes are siloed and not cross-functional. The integration between IT Processes and Business Processes is even not considered despite the fact that all Business Processes should be linked to IT Processes. The processes and activities of a Line of Business have Incidents, Problems, issues with availability etc…

The first step would be to have for the IT department a Service Manager (e.g. ITIL) to coordinate all the processes related to IT Service Management. On a parallel, the Business should also have owners for their processes.

Recently I was looking at some documentation related to the SAP ESA (Enterprise Service Oriented Architecture) and found a very interesting comment from Shai Agassi, member of the SAP Executive Board and president of the SAP Product and Technology Group (PTG). He claimed that “Chief Information Officer” function is morphing into two distinctive roles: the Chief Process Innovation Officer (CPIO), and the Chief IT Officer (CITO, to coin a new acronym). In this new model, the CPIO is in charge of innovative business processes and continuous process integration.”

All processes have definetly to be coordinated, IT or not in a consistent way. As improving processes allows to bring innovation, this new role (Chief Process Innovation Officer), would allow companies to create new synergies, between the Business and IT, considering the CPIO as a partner of LOBs, in charge of processes deisgns with the business’ network. That position would require new skills to be developed as part of the IT organization. Such a role would be the best way to create an harmony for IT/Business processes.

Business Continuity and Business Architecture

Are there any potential relationships between these two domains? Maybe yes…

Very often Enterprise Architecture programs start with a bottom up approach as this is easier to justify. A bottom-up approach involves setting infrastructure standards and introducing governance processes to ensure adherence to those standards, while a top-down approach dictates a formal analysis of the current state with respect to business process, application programs, data, and technology components.

Top-down start with Business Architecture once the Business strategy and organization is well known, but how to be able to quickly justify some sort of return on investment when no real Business Process Management initiative is associated?

Disaster recovery efforts can be extremely costly, both in terms of technology replacement and business interruption. But giving users access to the exact same work information through another connectivity path is a big step toward business continuity.

Often a major factor in the decision to provide only limited recovery facilities is the cost of having “redundant” office space ready to use just in case of an incident. These limited recovery facillities are associated to limited IT Services because rarely all applications and systems have redundancy. Choices have to be made… but on what criterias? How do we manage existing Business Processes if these are no more automated?

Business Architecture can be an answer!

Business Architecture programs limit the depth of the program to business architecture, and are typically driven from the top-down, with corporate planning and strategy, or change management as the sponsor of the program. The architecture team is typically comprised of business process experts, and has a close relationship to their specific Lines of Business. Business Architecture teams in companies that are “process organizations” typically have the mandate to define business processes that span the company.

Associating Business Architecture to Business Continuity can therefore help to quickly justify a top-down approach as key processes needs to be documented for a disaster recovery effort.