LinkedIn: Does process need to be Re-Branded?

<question group="Business Process Improvement">
Does process need to be Re-Branded?
For those in the BPI/BPM space, the reason that process is in the middle of People, Process and Technology is not just because it sounds better. Process is the meat of the People and Technology sandwich. People and Technology can be very efficient, add a so-so process and you can get greater efficiency.

However, transform the process to drive the business model and you change an efficient process to an effective one.

So after all these years of Six Sigma, Lean, TQM and others why is process management not a top executive level activity.

Is the reason that process and process management have a negative reputation? Say the word process and do you hear response phrases like 'red tape', 'get in the way', 'stifles innovation and creativity' and 'process gets in the way'?

If this is the case, than is it time that we re-brand process.

Seeking your thoughts for or against and if for, ideas on how to re-brand.

</question>

I also noticed that “process management have a negative reputation” but I am not sure that just re-branding will help. I start from education.
(repeating from another discussion) We observed that architecting/implementing BPM systems requires a lot of communication with practically everyone within the enterprise and everyone should be treated as a stakeholder of the BPM system.

Each group of stakeholder has different views, different concerns and different understandings of the BPM system. Those groups are:
• top managers
• business managers
• process owners
• super-users
• users
• project managers
• business analysts
• IT managers
• IT architects
• IT developers
• IT operators

It is mandatory to explain to each stakeholder (not just CxO) how their concerns will be addressed and how their current working practices will be changed for the better. If all subordinates are happy with a new tool, i.e. the BPM system, then CxO has "no choice".
As a first step, I think, this requires “BPM reference model” which can bring a commonly agreed terminology and improve understanding. Certainly, such a model should not come from a vendors-dominated group, but from a customer-advocates group. Does such a group exist?

Thanks,
AS

LinkedIn: What do you think is the essential difference between an architect and a designer?

<question group="The IT Architect Network (3000+)">
What do you think is the essential difference between an architect and a designer?
</question>

I use the article (Architecture, Design, Implementation, A. Eden and R. Kazman, International conference on software Engineering – ICSE, May 3-10, 2003, Portland, OR.) which illustrates the distinction between architecture, design and implementation by the Intension/Locality thesis:
• architectural specifications are intensional (i.e. there may be many possible instances) and non-local (i.e. mandatory for all parts of a system);
• design specifications are intensional but local;
• implementation specifications are extensional (i.e. only one instance is possible) and local.

Thanks,
AS

LinkedIn: What is a Service?

<question group="Service Oriented Architecture Special Interest Group">

What is a Service?
I'd like to discuss the differences between concepts such as business services with Real World Effect, interfaces as an implementation of a service, etc.
i think I see thre levels of "service". The high level is the service in terms of what it provides to the business consumer.
the second is the interface design to implement it. The third is the method design within the interfaces.
Unfortunately, the term "service" can be used to describe each of these, making "context" very important.
Also, where does statelessness fit into these?
Is it ok to use state at the interface or method layer to handle complex service calls, provided the business service is stateless?

</question>



From my terminology...

SOA, noun

architectural approach for constructing software-intensive systems from a set of universally interconnected and interdependent services

service, noun
explicitly-defined and operationally-independent unit of functionality

Remark 1: Explicit definition means that a formal description of the service (i.e. the input, the output and other contractual information such as the duration of the contract) exists. This explicit definition should be the subject of agreement between the service provider and the consumer.

Remark 2: Operational independence means that problems in one service do not affect the functioning of another service if the latter does not use the former, i.e. some services are autonomous with respect to other services. For example, a garage may provide both a repair and a sales service. Even if the repair shop is on vacation the sales shop can still function; the services are thus operationally independent.


process, noun
explicitly-defined coordination of services to create a particular result

Remark 1: Services and processes can be considered to be intimately related since in real terms
• all processes are services,
• some operations of a service can be implemented as a process, and
• a process includes services in its implementation.

Thanks,
AS

Question on the path from enterprise metadata to specific instance data in the process of designing soa artifacts...

<question>

I'd like to hear your opinion on the subject of metadata management in the context of production of SOA artifacts.
It is clear that the advantage of defining upfront a process that becomes executable removes the burden of decomposing it into messages and behaviours to be allocated to the existing IT silos, which would imply a strong risk of loosing track of the process itself. That is the mission of BPMN getting translated to an executable representation *such as BPEL or XPDL
This approach allows us to progressively refine the process' activities until we get to a level of detail at which activities can be mapped to simple logic to be performed by the bpm engine itself or to calls to specific external services.

But, what happens to data?
Data exists in the form of xml schemas, or database table relationships, all this is very low level, and comes into play at the very end of the development process. In a huge enterprise, I guess, some sort of common datamodel abstraction should be created so that the early versions of the BPMN diagram refer to data that is understandable at the correct level of abstraction (i.e the notion of "Customer"), in order to be refined, afterwards in specific domains and data formats (of type prepaid identified by an MSISDN of format xxx/xxxxxxx stored in application XYZ as a row in a specific db to be exsposed as a data service).

How would you address the need to store this vertical relationship of data concepts (from business data, to specific domain data, down to application instance data schemas) in a way that allows the business process modeler to refer to the customer and the domain analyst to narrow down on the specific type of customer and the developer to map that to the correct schema?

Where would you put this sort of relationship and shouldn't it be integrated with the development tools somehow?

I hope to have made my self clear.

Regards.

</question>


Good and huge question!

Your general approach is correct. You are also right that there is a vertical relationship (business objects, business data and application data) and not every BPM tool provides good tools for handling such a relationship.
Please, have a look at the illustration below -- this is a multi-layer model from my book.

http://www.improving-bpm-systems.com/book/2-the-architectural-framework-for-improving-bpm/approach-framework.png/image_view_fullscreen

Each layer is a level of abstraction of the business and addresses some particular concerns. Let us discuss the bottom four layers here.

• The business execution layer carries out the business processes. Any process comprises one or more business activities which are a mixture of human and automated activities. For example, the following is a sequence of three activities on a product: sign-off the product (obviously this is carried out by a human), put it into a web-store and announce its availability. At this level of abstraction the business is a systematic set of coordinated activities. We can say that this is the layer where unit managers and super-users work. This layer is usually expressed in BPMN.

• The business routines (or regulations) layer comprises the actions which must be carried out on the business objects to perform the business activities. For example, to announce the availability of a product one has to find out which clients are interested in the product, to collect their contact e-mails and to distribute an announcement. At this level of abstraction the business comprises some modifications (including the adding of value) to the objects. Most enterprise employees work in this layer.

• The business objects layer comprises the many objects specific for a
particular business, e.g. a business partner, a product, etc. This layer hides the complexity for manipulating the objects, which are actually collections of data together with any dependencies between them. The level of abstraction is increased — the business is represented by the objects, irrespective or not of the repositories.

• The business data layer comprises many pieces of information — names, dates, files, etc., which are stored in existing repositories, e.g. databases, document management systems, Web portals, directories, e-mail servers, etc. This layer's role is to access data. In this layer the business is considered in a very primitive way.

The business objects are expressed in XSD in the way to be convenient for _transportation_ information between layers (actually, between services presenting layers), mainly between business execution and business routines layers. You will need to define such XSD as repository/application independent. If you have an enterprise data dictionary then it is a good place to start, but think about transportation of information.

The business data layer is usually very straightforward and is based on existing API for a particular repository. Usually that API uses CRUD pattern.

Interfaces for business objects layer should be more comprehensive than CRUD; for example, some business objects may be versionable and handling of many versions should be exposed. A particular business object many be composed from business data coming from different repositories. Also a particular business object may be stored in several domains (or repositories); for example, one domain (repository) is a master and others are just copies. Something I create explicit business sub-objects, e.g. Customer in CRM (master), Customer in Billing (copy), etc. There are also issues like the following – a modification of a data element has to start a process, e.g. changing of customer’s address may lead to changing his/her insurance contract.

In general, business objects layer is a “virtual data hub” or “master data management facility”, but with the interface better than just CRUD.

Hope this helps.

Thanks,
AS

LinkedIn: Is it now time for Process professionals to step up to the plate to make significant performance improvements at your financial institution?

<question group="BP Group">
Is it now time for Process professionals to step up to the plate to make significant performance improvements at your financial institution?

Why will your CEO find it difficult to take your advice?
There has never been a more difficult time for financial institutions in the last 100 years and more than ever they need the contribution of the Process professionals. And yet CEOs, CFOs and COOs are highly sceptical about the contribution that process thinking can provide.

- Why is this the case?

- So how can you bridge this credibility divide?

- What should you do now?

Read more from the International Banking Systems featured interview with me at http://tinyurl.com/6xdpnw

Fedback and comments welscome here on the challenges discussed.

Regards John

www.ibspublishing.com/index.cfm?section=features&action=view&id=12544


</question>

We observed that architecting/implementing BPM systems requires a lot of communication with practically everyone within the enterprise and everyone should be treated as a stakeholder of the BPM system.

Each group of stakeholder has different views, different concerns
and different understandings of the BPM system. Those groups are:
• top managers
• business managers
• process owners
• super-users
• users
• project managers
• business analysts
• IT managers
• IT architects
• IT developers
• IT operators

It is mandatory to explain to each stakeholder (not just CxO) how their concerns will be addressed and how their current working practices will be changed for the better.

If all subordinates are happy with a new tool, i.e. the BPM system, then CxO has "no choice".

Have a look at my presentation this summer in Bangalore - http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote.pdf

Thanks,
AS

BPM system is a portfolio of business processes of an enterprise as well as the practices and tools for governing its design, execution and evolution.

Of course, a BPM suite (coherent set of software tools) should be used to facilitate implementation of the BPM system.

LinkedIn: Is it fair compare a Business Architect to a building architect?

<question group="Business Architecture Community">
Is it fair compare a Business Architect to a building architect?
Really, does it even make sense? I have been one that used the analogy, but is it a good analogy to use? Why is it that many of us use this one? I know both are hard, both document and are trying to create "blueprints", but...

There is very little science or agreed upon anything when it comes to business architecture. There is no standard certification that is respected by everyone. There is no set of common deliverables you ALWAYS do. There is no governance of business architecture from an industry standpoint. There is a lot of trial and error in business architecture.

This is a great contrast from a building architect. There is rigor and respect when it comes to licensing. There are standard deliverables. There is extreme rigor on governance - building inspectors, laws of physics, etc...

What are your thoughts?

</question>

At first, let’s back to basics to align our understanding.
In the civil architecture in each construction project there are three distinct roles: a client (an individual, or an organisation), a civil architect (a licensed individual who leads a team in the planning and design of buildings and participates in oversight of building construction) and a general contractor (a company which constructs buildings).

A client (maître d’ouvrage) contacts first a civil architect (maître d’œuvre) to communicate his/her "dream"; the latter presents to the client a solution (in some kind of a visual form, e.g. as a drawing or a scale model, because the aesthetic is often very important). After accepting the solution, the civil architect is empowered by the client to guarantee a good way of the construction. The civil architect selects a general contractor and the civil architect works with a foreman (contremaître) – an experienced professional who is in charge of with organising the overall construction including the construction crew.

The separation of duties between these roles is very important – a civil architect and a general contractor are different individuals or companies by obligation (at least in some countries). Such a separation guarantees the appropriate control and quality upon the results. Also, it is interesting to note that there is no an explicit project manager role per se – each role has to carry out some “project management” duties for itself. For example, a foreman is actually a project manager from the side of the general constructor (considering that he/she has come to the management position after experience as a construction worker, but not a professional project manager).

Just guessing the mapping of roles in your case. For example:
“client” = the whole organisation
“architect” = a business architect
“general contractor” = the whole IT department + many external consulting companies
“client’s dream” = merger, changing of unit’s structure, survival in heavy competition, cost cutting, modernisation of legacy applications, outsourcing the whole unit or just its IT environment, portfolio rationalization, etc.

Does it match your reality?

In any case, a business architect has to be armed with a coherent set of proven tools and practices which provides guidance and practical help for the effective transformation of an enterprise to achieve business vision and strategy (i.e. client’s dream).

Of course, a business architect has to work with many step-by-step improvements. We found that the most difficult is to deal with two streams of improvements – those for implementation of the “client’s dream” and those for improvement of the business system itself. The latter are also related to the “client’s dream”, but rather indirectly. Nevertheless, both streams are important, interdependent and to have be intermixed – in some sense a particular business system should be properly “trained” before realising great “client’s dream”.

So far, the most promising approach is a mixture of BPM+SOA as major tools and many supporting ones. (Like in the chess game – it is necessary to play with all chess mates together.) Artefacts, nomencltures, methods, patterns, recomendations etc. are available for this approach.

(Have a look at my talk this summer in Bangalore - http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote.pdf)

Thanks,
AS

LinkedIn: How would you define a "business architecture?" And how would you show ROI on developing one?

<question group="Service Oriented Architecture Special Interest Group" >
How would you define a "business architecture?" And how would you show ROI on developing one?
My understanding is that a business architecture is comprised of an enterprise core and supporting processes, business process maps or models for these processes, and how the technology aligns to them.
What else would you add to this definition?

</question>

From my terminology...

business architecture, noun
part of enterprise architecture concentrating on the conceptualisation and evolution of the form and structure of the enterprise business system

Remark: The issues of greatest importance for business architecture are the following:
• core end-to-end business processes (also known as value streams);
• governance structures;
• core business information (semantics);
• communication with core business partners.


enterprise business system, noun
top level view of an enterprise as a system for conducting the business


enterprise architecture, noun
coherent set of proven tools and practices which provides guidance and practical help for the effective transformation of an enterprise to achieve business vision and strategy

Remark 1: Examples of business vision and strategy are: higher level of maturity, greater agility, better collaboration, merging, cost cutting, modernisation of legacy applications, outsourcing the whole unit, etc.

Remark 2: Some parts of enterprise architecture are dedicated to different stakeholders.

Thanks,
AS

LinkedIn: Is BPMN portability important to you?

<question group="BPM Guru" >
Is BPMN portability important to you?
There have been a number of blog posts recently on how to provide the underpinnings to allow one to prove correctness of a BPMN diagram. This is necessary to allow a diagram to be carried from one vendor tool to another. If you can't prove that it is correct, then different vendors may have different interpretations, and you fail to achieve portability. Interesting posts:

http://www.brsilver.com/wordpress/2008/09/21/model-portability-in-bpmn-20/

http://kswenson.wordpress.com/2008/09/29/will-bpmn-20-have-model-portability/

The BPMN standards committee has not responded in this discussion for compliance criteria. WfMC is trying to provide compliance criteria, including levels of compliance, for BPMN inside the XPDL work. As the OMG officially distances itself from WfMC, this work might be contradicted by OMG group. That does not help anyone. We need the official compliance criteria to be in the official BPMN spec.

My question is: Is it important for the BPMN standards committee to focus on Model Portability?


</question>

I think that model portability in BPMN is very critical.
Ideally, I would like that BPMN quickly and without repeating errors will reach the existing level of XHTML -- a clear set of elements, power of XML, control of interpretation by CSS and extra flexibility by DOM+API.

"What you model is what you execute" is the goal. How the execution is implemented - via BPEL or not - is another question (for example, an HTML document can be rendered with PostScript). Of course, the execution semantic of BPMN must be well-defined and being validatable.

Thanks,
AS