2008-12-30

Comment 7 on "Anti-pattern: End-to-End Process Orchestration" comment 6

Anatoly,


I think that just having more than one pool within a BPMN diagram is not enough to consider it as choreography. My feeling: the difference between orchestration-dominant and choreography-dominant processes is in their behaviour. The former have “globally predictable” behaviour. The logic of templates (one pool implies one instance) is enough to implement such processes.


Diagram below (process for “selection of the best offer”, optimistic case) I would consider as choreography – its behaviour is less predictable. The logic of instances is required, because pool “VENDOR” actually implies many instances (one per each vendor involved in a bid).




Of course, in BPMN all vendors operate in the same way and that is perfect from the point of view of the company (i.e. pool “COOR”), because the company has to prove that all vendors are treated equally. In some sense, pool “VENDOR” acts as vendor’s proxy (or insulation layer). This allows us to make such coordination more explicit (easier to validate, control, monitor, certify, etc.)

Thanks,

AS

2008-12-26

Comment 4 on "Anti-pattern: End-to-End Process Orchestration" comment 3

Anatoly,

I think, that diagramm is "process orchestration". 

Yes, I should use BPMN instead of English next time.

Thanks,
AS 

2008-12-24

Comment 2 on "Anti-pattern: End-to-End Process Orchestration" comment 2

Anatoly,

More comments, please.

4) My point is that novice BPM desingers tend to use former model but the latter is more realistic.

My interpretation: they (novice BPM desingers) model the process from the point of view of one of the participants – “customer”; after they have to model from the points of view of other participants, e.g. “dealer”, “production”, etc., and finally, a common view should be synthesised. So, I would say that this is just uncompleted work.


5) Branches from a parallel gateway may go over other pools? I seriously doubt this. Not in BPMN. But you are right: parallel gateways do produce asynchronous threads.

Is illustration below “process orchestration” or “process choreography”?





6) My favourite analogy to process choreography is threads programming in java.
I would treat “process choreography” as coordination between threads from different java programs -- System.exit() at one pool should not stop a particular choreography.

Thanks,
AS

2008-12-23

Comment on "Anti-pattern: End-to-End Process Orchestration"

Comment on http://mainthing.ru/item/131/

1) Definition:
“Enterprise Process” (equivalent term “End-to-End Process”) is a business process connected to external customer at both ends and going through more than one top-level company’s departments.

More fundamental characteristics of enterprise processes are: a) core business and b) value-added. Those are main reasons that “a BPM initiative would pay for itself”.

2) “Order-to-cash” process

Please, be more precise. If a company produces a service (an intangible product) then there is no manufacturing. Also, some goods, e.g. normal cars in customer’s configuration, will be produced only after the order from a customer!

3) “Process Orchestration” means tasks execution sequence and logic within a single process frame. “Process Choreography” means the logic of several processes asynchronous execution coordinated by data/message flows.

This separation is not clear. Assuming that “single process frame” is a BPMN pool then one can have “execution sequence” spread over many pools exchanged with “data/message flows”. Even more, branches from a parallel gateway are executed asynchronously (and they may go over other pools).
My feeling: orchestration is similar to normal programming with functions (subroutines), while choreography is more close to co-routines.

Thanks,
AS

2008-12-13

Linkedin: Top Down or Bottom Up ?

<question group="BP Group">
Top Down or Bottom Up ?

Do we begin with a Top Down or Bottom Up approach when starting with BPM ?
Trying to figure out how BPM works is like solving a giant jigsaw puzzle. You can approach it in one of two ways. Using the “top down” approach (Process Architecture) , you start with the image of what the solved puzzle should look like, and use this to decide which pieces to ignore and which pieces to search for. The other approach is “bottom up” (Six Sigma), where you focus on the individual pieces themselves. You study them for unusual features and look for close matches with other puzzle pieces. If you don’t have a picture of the puzzle’s solution, the “bottom up” method is sometimes the only way to proceed. Lacking a good framework for understanding processes, organisations have been forced to stick with the “bottom up” approach. This tasks is Herculean if not impossible, with a puzzle as complex as an organisational structure.

Imagine a jigsaw puzzle with several thousand pieces. Many of the pieces can be interpreted multiple ways, as if each had an image on both sides but only one of them is right. All the pieces are poorly shaped so you can’t be certain if two pieces fit together or not. Many of them will not be used in the ultimate solution, but you don’t know which ones or how many. Every month new pieces arrive in the post. Some of these new pieces replace older ones, as if the puzzle maker was saying, “I know you’ve been working with these old puzzle pieces for a few years, but they turned out to be wrong. Sorry! Use the new ones instead until further notice.” Unfortunately, you have no idea what the end result will look like; worse, you may have some ideas but they are wrong.



</question>


From my recommendations for building enterprise BPM systems
<quote>
4.6 Avoid the trap of the selection of “top-down” vs. “bottom-up” – use the “pinball” style

Another typical symptom of getting stuck in the design phase of your BPM system is the existence of endless discussions about the necessary “granularity” of the services:

“If we select a top-down style then we will create coarse-grained business-related services, but we are not sure whether such services are implementable or reusable. If we follow a bottom-up style then we will implement too many fine-grained services for which the business value is not obvious.”

Actually, any such discussion is misplaced at this stage. What should be discussed is how to build future flexibility into the enterprise BPM system which will allow the rapid and painless adaptation of services to increase or decrease their granularity. Small and agile improvements may be required in different layers – rather like the multiple refinements of a ball trajectory in a pinball machine.

This pitfall is extremely common, so take care! We think its root is in the traditional (vs. agile) development practices which aim to provide a perfect system straight away – in such a system all services shall have the “right” granularity.
</quote>

I agree about the analogy with puzzle. I used it for my business process modelling procedure, see http://www.improving-bpm-systems.com/pubs/AS-BPMDS08.pdf

<quote>
In some senses, modelling is similar to solving a puzzle – everyone has his/her own way, but there are a few practical tips, e.g. make the edges first, group together pieces with a similar colour or pattern, collect them into clusters, use the latter as “centres of crystallisation” and then fill in the rest. But, there are a few real-life difficulties: you have to do many puzzles at the same time, to use pieces from other puzzles, to cut new pieces, to optimise the number of pieces, to transform some puzzles, etc. It should be a lot of fun!
</quote>

Thanks,
AS

2008-12-12

Linkedin: I NEED INPUT ON A WHITE PAPER. CAN YOU PLEASE REVIEW THE LINKED ARTICLE?

<question group="Business Process Improvement">
I NEED INPUT ON A WHITE PAPER. CAN YOU PLEASE REVIEW THE LINKED ARTICLE?
.

www.OnTheSystem.com/everything

</question>

I like the idea of a simple theory which will help us to improve enterprises.

Some of my ideas from http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote.pdf

An enterprise BPM system is a dynamic set of artefacts (or building blocks?)

Artefacts are interconnected and interdependent

We have to anticipate potential changes: policies, priorities, compliance, technology, etc.

Implementation of such changes necessitates the evolution of some artefacts and the relationships between them

It must be easy to modify all artefacts and relationships without causing any negative effects

Principles:
- All artefacts must be evolved to become digital, external and virtual
- All artefacts must be versionable throughout their lifecycle
- All relationships between these artefacts are modelled explicitly
- All models are made to be executable

Thanks,
AS

2008-12-07

LinkedIn: What's your experience on failure of CORBA and EJB?

<question group="International Association of Software Architects">
What's your experience on failure of CORBA and EJB?
The Rise and Fall of CORBA

http://acmqueue.com/modules.php?name=Content&pa=printer_friendly&pid=396&page=1

</question>

I used CORBA successfully in Java, Unix and Windows environment. Still remember the IDL and simplicity of the naming service from Visibroker. Wish that modern tools would match them soon.

I didn’t write “nontrivial CORBA applications”. I used CORBA as a tool to connect distributed services -- similar to modern ESB. Together with service coordination (via a workflow tool) and implementation of services in dynamic language (Jython) this worked fine. Versioning was externalised.

Thanks,
AS

LinkedIn: What is the difference between Enterprise Architecture, Business Architecture and the various other "X Architecture" names, interpretations

<question group="Business Architecture Community">

What is the difference between Enterprise Architecture, Business Architecture and the various other "X Architecture" names, interpretations and approaches?
Q1
Is there a difference or is it just semantics, causing confusion because of different naming conventions and promotion of individual view?

I have personally used "Business Ecosystem Architecture" and "Symbiotic Architecture" to define through naming a difference in my own approach, always with a very heavy emphasis on it being a business (executive) driven requirement.

Following the above...
Q2
Should Business Architecture refer to:
- Business strategy dimension for EA
- Business processes that aligns with EA (TOGAF)
- Integrated operational ecosystem model
- Whole-of-Enterprise
- Symbiotic relationship design
- Your suggestion here…

</question>



From my definitions...

enterprise architecture, noun
coherent and proven set of principles, recommendations, rules, practices, and tools which provides guidance and practical help for the design and evolution of IT and business to achieve enterprise vision and strategy

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

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

Remark 3: To guarantee the desired outcome, enterprise architecture needs to be as good as applied science.

enterprise business system, noun

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

Remark 1: This top level view may concentrate on how the business is structured, what it does and what it needs to do to meet its goals.

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

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


Thanks,
AS

2008-12-05

LinkedIn: The Nitty Gritty: Can you explain to a CEO what makes an architect different?

<question group="International Association of Software Architects">

The Nitty Gritty: Can you explain to a CEO what makes an architect different?
Well we've been at this for some time and over the last few years have been able to answer this with more and more certainty. However before I post it I want to get some feedback from all of you.

CEO walks in to your office/cube/etc and asks,"I know why I hire good developers/PMs/BAs/IT Ops/etc, so why do I hire architects? What makes them different than other staff? And dont give me any of those mumbo-jumbo technical answers. Just boil it down to one sentence why I should let you keep your high-salary job." What do you say?

Try to answer in one sentence. Try to make sure the answer is VERY clearly differentiated from other roles. For example, "Developers write quality code based on business requirements.", "PMs deliver projects on time and under budget."

...And yes I will post the answer that has come from our research in the next couple of days.

</question>

An architect is someone who translates wishes, expectations, and dreams (e.g. survive in this financial crisis) of a client (you, Mr CEO) into a workable plan and guides others (developers/PMs/BAs/IT Ops/etc) in executing that plan.

See as well https://improving-bpm-systems.blogspot.com/2008/10/discussionenterprise-architect-user.html

In my experience, enterprise architects work simultaneously in the following positions :
  • Scribe who keeps up to date the documentation about EA artefacts and the relationships between them. This is the traditional role of an enterprise architect.
  • Scout who brings new technologies into the enterprise.
  • Salesman who finds good arguments for investments in not-so-obvious improvements.
  • Superman who is usually asked to provide a quick rescue for a rotten IT project, often by completing during the weekend work that should have been done over many man-months!
  • Sociologist who has to understand the concerns and fears of everyone in the enterprise.
  • Servant who is at the service of all others in the enterprise.
  • Scientist who uses scientifically proven methods in his/her work.
  • Student who is ready to learn quickly new technologies, new tools and new business domains.
  • Shepherd who can guide others.
  • Secretary “de luxe” who helps others to do some work (although this may be considered as a rather low qualification, it is nonetheless important to achieve the common goal).
  • Skipper who can lead complex projects.
  • Swiss-knife which can solve any problems.
See also http://improving-bpm-systems.blogspot.com/2008/11/linkedin-is-it-fair-compare-business.html

Thanks,
AS

2008-12-02

Linkedin: Future of BPM. Your take on this?

<question group="Business Process Professionals">
Future of BPM. Your take on this?
http://www.aiim.org/ResourceCenter/AIIMNews/PressReleases/Article.aspx?ID=35328
</question>


My observations about BPM:

- no commonly agreed terminology (what does “BPMS” stand for?)
- no commonly agreed reference model
- no proper system of standards (BPMN, BPEL and XPDL have been developed by different groups for different purpose; these standards are not complimentary)
- current discussion about BPMN 2.0 is a battle between BPM vendors; BPM customers are forgotten
- there are many BPM vendors (it seems that BPM is good business)
- everyone does BPM right now (even people who don’t know the difference between process template and process instance)
- potentials of BPM/SOA are huge
- each BPM project is re-inventing the wheel
- no organisation which protects BPM customers

My conclusions:
- future of BPM is bright – maybe not for BPM customers yet
- the main challenge is how to turn BPM from being vendors-driven to become customers-driven? (good example is a set of W3C standards around HTML – each Web browser vendor compares its product against the ACID3 test)

Thanks,
AS

2008-11-22

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

2008-11-15

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

2008-11-13

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

2008-11-07

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.

2008-11-06

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

2008-11-05

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

2008-11-04

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

2008-10-23

Anything Enterprise Architecture: forming an EA group

<question >
Hello All

I just joined this group and reading up on EA and its roles etc. I have been given the task of forming an EA group and then present that to management. I wanted to seek help to point me in the right direction.

Q) where do I start
Q) wanted to use some business examples(eg finance, or sales at my company) and present to management where each EA roles fit in
Q) how EA will help improve things etc

Thank you all
</question>

May share with you my draft...

The vision statement
Experience shows that business wants separate requests for change to be implemented quickly. These changes are typically small (from the point of view of the business) and unpredictable (from the point of view of IT). To carry out these changes easily and in a managed way, the enterprise (as a complex and dynamic system) must be properly architected and implemented, thus becoming a platform for business improvements including innovations and optimisations at any scope.

The mission statement
The mission of the EA unit is to provide to stakeholders (top managers, business managers, process owners, super-users, users, business analysts, IT managers, IT architects, IT developers, IT operators, and partners) clear guidance and practical help for transforming the enterprise to implement any given vision (merger, higher level of business agility, etc.).

The objectives
The EA unit develops and maintains the enterprise architecture framework as a comprehensive set of recommendations, models, patterns, examples, tools and training materials.
The EA unit provides a dedicated version of this set (in a form of an implementation guide) to each type of stakeholders. Each implementation guide explains to stakeholders how the enterprise architecture framework addresses their concerns. Each implementation guide practically helps particular stakeholders effectively and efficiently participate in the transformation.

Thanks,
AS

2008-10-20

LinkedIn: Given a blank sheet of paper how would you go about driving business value from an Enterprise Architecture roadmap?

<question discussion="The Enterprise Architecture Network">
Given a blank sheet of paper how would you go about driving business value from an Enterprise Architecture roadmap?

There are various models around that discuss how IT / Architecture should create a roadmap to support the business. Seems that none of these actually talk (apart from in brief) about how a business stakeholder will realise tangible benefits from an EA strategy. There is lots of discussion around consolidation / simplification etc.. but no one can answer the question "yeah I get all that but what does all that mean to ME?" - interested in all views.

</question>

The second part of the presentation -- see URL below -- shows how EA (with the use of BPM and SOA as main tools for enterprise performance improvement) can address concerns of different stakeholders (from top managers to users and IT operators).

http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote.pdf

Thanks,
AS

2008-10-19

LinkedIn: I have conducted tons of research regarding the 'enterprise architect'. And, it seems that the 'jury still out' as to what

<question discussion="Enterprise Architect User Group">
I have conducted tons of research regarding the 'enterprise architect'. And, it seems that the 'jury still out' as to what (education, experience and skill) makes a great enterprise architect.

The questions I am attempting to answer are relatively simple:

(1) Please describe what you believe to be an ideal candidate for an entry level enterprise architect position. What would one look like in terms of education, skill, and experience?

(2) Please describe a great veteran enterprise architect, including their education, skills and background?

Please be specific (e.g. education - MBA, PhD, etc.).

</question>


Transgrowth.com website provides an excellent definition of “architect”:
An architect is someone who translates wishes, dreams and expectations of a client into a workable plan and guides others in executing that plan.

In the case of enterprise architect, the "roles" from this definition can filled in the following way:
“client” = stakeholders, top management
“wishes, dreams and expectations” = merger, changing of unit’s internal structure, survival in heavy competition, cost cutting, modernisation of legacy applications, outsourcing the whole unit or just its IT environment, portfolio rationalization, etc.
“others” = the whole enterprise

In my experience, enterprise architects work simultaneously in the following positions :
  • Scribe who keeps up to date the documentation about EA artefacts and the relationships between them. This is the traditional role of an enterprise architect.
  • Scout who brings new technologies into the enterprise.
  • Salesman who finds good arguments for investments in not-so-obvious improvements.
  • Superman who is usually asked to provide a quick rescue for a rotten IT project, often by completing during the weekend work that should have been done over many man-months!
  • Sociologist who has to understand the concerns and fears of everyone in the enterprise.
  • Servant who is at the service of all others in the enterprise.
  • Scientist who uses scientifically proven methods in his/her work.
  • Student who is ready to learn quickly new technologies, new tools and new business domains.
  • Shepherd who can guide others.
  • Secretary “de luxe” who helps others to do some work (although this may be considered as a rather low qualification, it is nonetheless important to achieve the common goal).
  • Skipper who can lead complex projects.
  • Swiss-knife which can solve any problems.
So, an ideal candidate has to be good in these positions; the great enterprise architect masters them (e.g. a scientist with PhD in an applied science)

Thanks,
AS

2008-10-18

LinkedIn: Aswers: Have you developed a business process architecture?

<question>
Have you developed a business process architecture?
I am starting work on a business process architecture for my company, and would be really interested to hear:

* how you sold the benefits to senior management
* how you developed your architecture
* how you use it to help manage your business
</question>

These and similar questions are addressed in the "Improving BPM systems" (see www.improving-BPM-systems.com) -- a practical implementation guide of how to transform existing disparate IT systems into a coherent, agile and flexible BPM/SOA solution.

A presentation from the slideshare (see the URL below) gives you an overview of the foundation and some practical examples.

Thanks,
AS

Links:
http://www.slideshare.net/TransformationInnovation/architecting-enterprise-bpm-systems-for-optimal-agility/

LinkedIn: Answers: I understand that Six Sigma and other QA approaches are about mapping and documenting organizational processes, identifying

<question>
I understand that Six Sigma and other QA approaches are about mapping and documenting organizational processes, identifying weaknesses and of course recommending changes. What tools do you use to monitor that changes and calculate success?
I would like to say my question is completely benevolent, so up front I will say “it is not”. I believe there is a great opportunity to align a Business Process Management solution with a Quality Assurance program and I am seeking to connect with those who can help me determine if my feelings are correct. I would truly appreciate everyone’s thoughts on the subject and please offer suggestions on how to proceed?
Christian Murphy

</question>


Some experience with Business Process Management(definition: BPM, as a discipline, allows you to model, execute, automate, control, measure and optimize the flow of business process steps that span your enterprise’s systems, people, customers and partners within and beyond your corporate boundaries.) and ISO 9001 quality management system (which is process-centric approach since year 2000).

Often ISO 9001 is implemented as a “system based only on documents” even if they contain diagrams of business processes. While it must be a “system for an organisation to manage its business processes” and maintenance of the quality management system documentation is only one of the needs.

We found that basic quality management requirements can be embedded into a BPM / SOA system. In the quality management system we usually have three types of document: quality manuals, business procedures and records. A modern BPM suite allows implementing EXECUTABLE business procedures which generate reliable records (good for traceability and for performance measurements). So, instead of maintaining “paper” and “program” versions of the same business process, you will need to have only one source understandable for both people and computers. For example, one of my clients (related to Quality of Medicines & HealthCare) took a modern BPM suite to model all business processes by business owners; execution of these models will be next step for this client.

It is very important that your BPM / SOA system is easy to evolve (or agile) – this, of course, requires some architecting (see a presentation below).

Thanks,
AS

Links:
http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote.pdf

LinkedIn: Answers: How to prevent the hijacking of BPM/SOA projects by PMs who have never worked on the involved technologies (TIBCO, BEA, etc.)?

<question>
How to prevent the hijacking of BPM/SOA projects by PMs who have never worked on the involved technologies (TIBCO, BEA, etc.)?
I am currently facing and have faced this problem before where project managers (who have never particpated in, let alone manage) completely mess up BPM and SOA technology projects by giving them a direction directly opposite to that proposed by the Lead Architect (who obviously has several years experience in the BPM/SOA domain).

How should architects engage with the Project Management Office at the beginning of the project? What is the level of empowerment that should be provided to architects who usually do not have a team of developers reporting to them.

The challenge remains of making a PM execute a project that is aligned to the development methodology proposed by the architect. Any insight into this based on current or previous experiences would be appreciated.

Cheers,
Sid

</question>

I would recommend to consider socio-technical nature of BPM/SOA: *how* you do something is sometimes more important than *what* you do.

If an architect (literally "chief builder") is a person who translates a user's requirements in a built environment then "a user" is your best ally. Who is that "a user" in your BPM/SOA solution?

In my experience, a BPM/SOA solution has many stakeholders with different views, different concerns and different understanding:
• top managers
• business managers
• process owners
• super-users
• users
• business analysts
• IT managers
• software architects
• developers
• operators

ONLY the architect can explain to each of them how their concerns will be addressed and how their current working practices will be changed for better. It is important to give a correct explanation/story for each of them and use right wording, e.g. "a version of a document" means different things for a quality manager and for an IT developer.

You may have a look at my presentation below that follows this approach to explain to different stakeholders how a particular architecture brings "ability for easy evolution".

Please feel free to contact me if you need more detail.

Thanks,
AS

Links:
http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote.pdf

LinkedIn: Answers: Does implementing a Software within an organization impede continuous Process Optimization?

<question>
Does implementing a Software within an organization impede continuous Process Optimization?
- Time-Frame for Implementation (say for ERP) - at least 1.5 years
- Time-Frame for maturity and stabilization - 2-3 years
i.e. - even after 3.5 years the organization is still stuck at current state.

Considerations for changing the process -

- Cost of Change (customization cost)
- Consideration of impact on other modules
- Dependence on external third-party

Thus 3.5 years at current state followed by uncertainty and additional dependencies. So that brings me back to my question - Does implementing a software impede continuous Process Optimization?
</question>

My answer is “NOT NECESSARY” – if you architect your BPM system (a set of tools and practices to handle business processes as enterprise-wide important artefacts) for optimal agility (required level of agility may change over the time).

Of course, such architecture should define a set of principles, recommendations, examples, etc. for “implementing software” within your organisation. Examples of such principle are: “avoid dispersion of the business logic” (e.g. not embed it into ERP), “explicit is better than implicit” (e.g. keep your business processes in BPMN, but not code them in Java), etc.

In my experience, a properly architected BPM system (with explicitly and formally defined executable business process) will help you to
a) provide tools for better decision making– real models and real performance data can be used by popular process improvement disciplines as Lean and Six Sigma.
b) guarantee that your business system is capable to implement changes with required pace.

Some practical examples were presented this summer at the conference "Architecture World 08" in Bangalore, India (see below).

Thanks,
AS

Links:
http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote.pdf

LinkedIn: Answers: Trying to figure out if there's a BPM software people really like (or not)

<question>
Trying to figure out if there's a BPM software people really like (or not)
Over the years I bumped into quite a few BPM software systems, but from my side they always seemed either too complicated (i.e. the BPM portions of ERP systems), or focused on one specific industry (i.e. software QA systems).

Curious to know if anyone bumped a software they consider the ultimate solution for general BPM, which you'd be able to use for support common business processes, ranging from QA, to service system (ticketing), to customer support, sales cycles, maybe some simple supply chain management and whatever other simple process comes to mind that you can draw on a whiteboard.
</question>

Any BPM system is a socio-technical system, so _how_ you do something is sometimes more important than _what_ you do. This is the key for a BPM implementation which "people really like" -- the software is not the major issue. It is important to be able to explain to anyone with an enterprise how a BPM system with address people's concerns and how it will change people's working habits for the better.

Thanks, AS

LinkedIn: Discussions: Are citizens the government’s customers?

<question discussion="eGov Community">
Are citizens the government’s customers?
To what extend should a government treat citizens as its customers? What do you think? Are citizens customers? Or is it a bit more complicated than this?

</question>

In a couple of e-gov projects in Switzerland (cantonal and federal levels) we consider customers as partners. They are explicitly presented in governmental business processes.

Thanks,
AS

LinkedIn: What is your definition of BPM?

<question discussion="Business Process Management Professionals Group">
What is your definition of BPM? Also, who are some of the major players in the BPM space?
My company is looking to offer a BPM solution as part of our software portfolio and I’m just looking for more general information about BPM.
/question>

From my terminology...

business process management, BPM (as discipline)
a discipline, which allows you to model, automate, execute, control, measure and optimize the business processes that span the enterprise’s systems, people, customers and partners within and beyond the corporate boundaries.

Remark: BPM uses the following types of business artefact: events,
processes, rules, activities, roles, objects (data structures), objects (documents), audit trails, performance indicators, services.


business process management system or BPM system
a set of business process of an enterprise as well as practices and tools for governing design, execution and evolution of this set

Remark: Any process-centric enterprise has its own BPM system. That BPM system may not be perfect (e.g. some processes may be only documented on paper, some details are only “located” only in the minds of certain people, etc.), but it does exist.

business process management suite or BPM suite
a coherent set of software tools for facilitating the implementation of BPM systems

Abbreviation BPMS is very confusing because diiferent people use it with different meaning. So, better to avoid it or use it only for "BPM suite".

Thanks,
AS

LinkedIn: Discussions: What is your definition of BPM?

<question discussion="Business Process Management Professionals Group">
What is your definition of BPM? Also, who are some of the major players in the BPM space?
My company is looking to offer a BPM solution as part of our software portfolio and I’m just looking for more general information about BPM.
</question>

From my terminology...

business process management, BPM (as discipline)
a discipline, which allows you to model, automate, execute, control, measure and optimize the business processes that span the enterprise’s systems, people, customers and partners within and beyond the corporate boundaries.

Remark: BPM uses the following types of business artefact: events,
processes, rules, activities, roles, objects (data structures), objects (documents), audit trails, performance indicators, services.


business process management system or BPM system
a set of business process of an enterprise as well as practices and tools for governing design, execution and evolution of this set

Remark: Any process-centric enterprise has its own BPM system. That BPM system may not be perfect (e.g. some processes may be only documented on paper, some details are only “located” only in the minds of certain people, etc.), but it does exist.

business process management suite or BPM suite
a coherent set of software tools for facilitating the implementation of BPM systems

Abbreviation BPMS is very confusing because diiferent people use it with different meaning. So, better to avoid it or use it only for "BPM suite".

Thanks,
AS

Linkedin: Discussions: Where do I find a comprehensive list of BPM Design Prinicples?

<question discussion="Business Process Development">
Where do I find a comprehensive list of BPM Design Prinicples?
Although BPM's normally evolve as time progresses but a good first time design is very helpful in reducing the time required for the BPM to stabilise. Is there a comprehensive list of such design principles similar to those put forward by the GoF( Gang of Four )?
</question>

From my book...

We strongly recommend that you first establish a set of principles for building your BPM system. This set of principles must be agreed unanimously by all major stakeholders. Take, or make, the time necessary to obtain this agreement – it is a cornerstone for all the work that follows. Remember that ideas agreed by the group are priceless in comparison with those imposed from the outside.

Such a set of principles usually includes a few high-level design heuristics and decisions. (Useful information is found in the book “Toyota Production System” and “Art of System architecting”). But the actual content should depend on the assessment of your needs with respect to the task, and it should also take into consideration the needs of the stakeholders.

1. A few definitions can be useful

2. Endorse the “building block” architectural concept from TOGAF

Building blocks, services and processes can be considered to be intimately related since in real terms
• all our services are building blocks,
• all our processes are services,
• some operation(s) of a service can be implemented as a process, and
• a process may use services for its implementation.

3. Avoid modification of shrink-wrapped commercial or freely available software

4. Danger of premature optimisation

5. Avoid the trap of the selection of “top-down” vs. “bottom-up” – use the “pinball” style

6. Explicit is better than implicit

7. The big picture

8. Horizontal and vertical coordination

9. Long-running processes

10. Avoid dispersion of the business logic

11. The importance of business events

12. BPM stakeholders’ views

13. Digitalisation of artefacts

14. Externalisation of artefacts

15. Virtualisation of artefacts

16. You may break any principle provided that you master it

Sure that any of principle is just an advice. It is quite normal to break any them if you know the reasons which are behind a particular principle and how they do match to a particular situation. For example, in the chess game is it recommended to novices do not exchange the queen vs. a pawn, but such an exchange can be a part of a combination which leads to the checkmate.

Thanks,
AS

2008-04-24

Architecture and Process conference 2008, Bangalore

Small, but very interesting conference with excellent keynotes.

I gave two presentations







Thanks,
AS

2008-04-20

Training course "Modelling of business processes with an open source BPM suite" is available

This training is based on a forthcoming book “Improving business process management systems” (see www.improving-BPM-systems.com for details). The aim of this book is to address and eliminate the existing business-IT gap in a very practical way. The book provides an architectural framework which explains how to implement BPM/SOA systems which are easy to evolve thus achieving flexibility of the IT and agility of the business.

This training is an intensive teaching of the third part of the book which addresses business process modelling issues, including a set of guidelines for developing implementable business processes by modelling them as executable processes.

The training course will be customized for the needs of the client by linking the modelling issues with practical cases of business process management in the areas of electronic publishing, quality management, enterprise content management, enterprise application integration and production automation.


Day 1, first half, first quarter – theory of BPM/SOA

0 Introduce myself and planning
1 Concepts BPM & SOA
Exercise: Your company maturity level now and desired
2 Related concepts
Exercise: How the BPM system will change your working habits?
3 Some standards, tools, etc.
Exercise: Do you use other IT abbreviations & buzzwords?
4 Architecting your system
Exercise: A big picture for you company

Day 1, first half, second quarter – Introducing an open source BPM suite

5 Introduce an open source BPM suite
Parts of the open source BPM suite
Manipulations in the BPMN Designer
Full run
6 Typology of artefacts
Exercises: Describe BPM artefacts for your project(s)

Day 1, second half – Initial modeling

7 BPMN constructs
Learn the BPMN symbols and its usage
The core set
The complete set
Exercises: modeling of simple cases

8 BPMN Diagramming style and patterns
A few examples of difficult diagrams
WF patterns
Some practical patterns
Exercises: modeling of some patterns
Discussion of recommendations from other specialists (Dr Bruce Silver)
BPMN review from AU

9 BPMN Advanced features in the open source BPM suite
Human tasks
Sub-processes
External services

Day 2, Practical modeling

10 Modeling procedure
11 Practical modeling (including client's processes)

Days 3 and 4 – Workshops (optional)
Assisted modeling and execution of clients examples by the participants