Blog: Is Enterprise Architecture sociotechnical systems (STS) design ?

<discussion ref="http://beyondinformation.blogspot.com/2009/07/is-enterprise-architecture-social.html" />

As any modern enterprise is a socio-technical system then any enterprise-wide activity, e.g. EA, enterprise BPM, should explain to all stakeholders of this activity how this activity will address their concerns and improve their work. For detail, please, see the second part (from slide 23) of http://www.slideshare.net/samarin/architecting-enterprise-bpm-systems-for-optimal-agility-presentation


Thanks,
AS

Linkedin: How to modeling a monitoring process?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=5089143&gid=1834234&trk=EML_anet_qa_ttle-cDhOon0JumNFomgJt7dBpSBA" />

I would use the following pattern:
8.3.11 Decide, Execute, Control – DEC pattern
This pattern (see figure below) covers the case where a parallel branch complements the normal working activities. This branch provides a control mechanism – it comprises a human activity which allows somebody to watch what is happening with a particular process instance (in the same way that an observation window allows one to observe the workings of a turbine).



Thanks,
AS

Inside Business Architecture: End to End Process Optimization is Overrated

<discussion ref="http://insidebusinessarchitecture.ning.com/profiles/blogs/end-to-end-process" />

I think, it would be useful to _explicitely_ separate the e2e optimisation of process template vs the e2e optimisation of process instance. See for details a recent post -- http://improving-bpm-systems.blogspot.com/2009/07/linkedin-bp-group-soapbox-1-process-is.html

Thanks,
AS

Linkedin: Are You Prepared to Practice 3-Dimensional Process

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1062077&discussionID=4933019&commentID=4950034&goback=.anh_1062077#commentID_4950034" />

Very interesting discussion about “dimensions”. Try to contribute from the architecture side.

I think that any enterprise BPM system (see http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html for its definition) is a complex and dynamic set of interconnected and interdependent artefacts. For BPM the most important types of business artefact are:
- events
- processes
- activities
- rules
- roles
- objects(data and documents)
- audit trails
- key performance indicators (KPIs)
- services

The evolution of some artefacts and the relationships between them is necessary to accommodate typical changes in enterprise policies, enterprise priorities, compliance, technology, laws, etc. So, to be agile and responsive in business, it must be easy to modify all artefacts and their relationships without causing any negative effects (e.g. unexpected delays and undesired consequences) in any part of the BPM system.

I think that the four main architectural principles are necessary to achieve a high level of flexibility:
1. All artefacts must be versionable throughout their lifecycle.
2. All artefacts must evolve to become digital, externalised, virtual and components of clouds.
3. All relationships between artefacts must be modelled explicitly.
4. All models must be made to be executable.

More relationships are explicit and executable –> more knowledge about functioning of the enterprise -> more predictable results -> more rational decisions -> more comprehensive optimisation.

The best example of explicit and executable relationships between business artefacts is process -- who (role) is doing what (objects and activities), when (coordination of activities), why (rules), how (activities) and with which results (KPIs).

I think this approach follows the discussion, especially the previous post from Michael.

Thanks,
AS

Linkedin: BP GROUP SOAPBOX 1: Process is an Effect

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers&discussionID=4785748&gid=1062077&commentID=4815511&trk=view_disc" />


Re "... a much more complex process architecture" I offer the follow fragment from my docs.

<quote>
1.6 Your flexible BPM system will become an enabler for business innovations

A typical task for a BPM system is to balance the final added-value of the product against the overheads associated with restructuring and/or tuning the enterprise business system to create this added-value. Today market success is often based on offering personalised products for less overhead. This book is not about how to make your products better, different or more attractive for the market – this is for you to decide. What this book can offer is to help you reduce the overheads in doing so – your flexible BPM system will become an enabler for your business innovations.

Imagine that each product is handled by a personalised and dedicated “virtual” business micro-system. The micro-system is optimised for a particular product and evolves together with the product lifecycle (see figure below). As a result, any exception becomes the norm. Instead of reducing the number of variations and considering exceptions as a loss in productivity (“20 % of the work takes 80 % of the time”) all products are treated equally. Of course, this is already the case for the manufacturing of expensive products such as aircrafts, cars and, to some extent, computers, but such an approach is also applicable to a wider range of commodities, especially those treated/handled with software-intensive systems.



</quote>

Thanks,
AS

LinkedIn: Survey Finds BPM Projects Lack Architecture -- Redmond Developer News

<discussion ref="http://www.linkedin.com/newsArticle?viewDiscussion=&articleID=47812036&gid=1062077&trk=NUS_RITM_more" />

Architecture (as an architectural framework) is ready for BPM projects -- see http://www.slideshare.net/samarin/architecting-enterprise-bpm-systems-for-optimal-agility-presentation

This architectural framework is designed to help architects to translate a customer’s requirements into a viable plan and to guide others in its execution.

Thanks,
AS

Blog: Process Anti-pattern: “One Man Show”

<discussion ref="http://mainthing.ru/item/166/" />

I think that both Anatoly's diagrams are anti-patterns. Previous comments gave a good explanation about the second case. Also, there are many different considerations (e.g. be ready for future changes, avoid mixing of added-value and mechanical activities, etc.) to present some work currently done by the same "person" into a set of activities.

I would like to use the first diagram as a "stress test" for BPMN - how a middle-man management can be expressed as a process. This pattern (called MMM) is an example of decentralised coordination. There are four participants who/what share the coordination: buyer(B), manufacturer (M), middle-man (MMM) and a common-sense procedure for mutual agreement (AGREE). Each participant has his/her/its own pool which contains participant's view of this process.



From the picture, it is obvious that MMM does no useful work -- just dispatching events+data others.


Thanks,
AS

Blog: Architecture Frameworks Don’t Make Architects

<discussion ref="http://jpmorgenthal.com/morgenthal/index.php?entry=entry090630-151756" />

Sure that classic EA frameworks create some kind of “enterprise genotype” (a full nomenclature of enterprise artefacts) which is not yet well connected to “enterprise phenotype” (a set of observable characteristics such as performance). This is one of the reasons for current difficulies with the construction of business systems which match clients' expectations. (I would like to have EA as good as an applied science).

I think that a formal link between enterprise genotype and enterprise phenotype can be done via “enterprise executable model” – EA enhanced by BPM and SOA (see http://www.slideshare.net/samarin/architecting-enterprise-bpm-systems-for-optimal-agility-presentation )


Thanks,
AS

ebizq.net: Join the Debate: Business Process Management or Business Process Automation

<discussion ref="http://www.ebizq.net/blogs/bpminaction/2009/06/join_the_debate_business_proce.php" />

To debate efficiently, I would start from definitions of three different concepts under BPM "umbrella" (see also http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html)

BPM discipline, noun
discipline which allows you to model, automate, execute, control, measure and optimise the flow of business activities that span the enterprise’s systems, employees, customers and partners within and beyond the enterprise boundaries

Remark: At present, the BPM discipline is the best way to implement process-centric enterprises.

BPM system, noun
portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio

Remark: Any process-centric enterprise has its own enterprise BPM system. The enterprise 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.

BPM suite, noun
coherent set of software tools for facilitating the implementation of a BPM system


So, in accordance with these definitions, business process automation (BPA) is an integral part of the BPM discipline. We implement BPA within enterprise BPM-systems with the help of BPM suites.

Thanks,
AS

ebizq.net: Are Organizations Developing BPM Solutions From a Top-Down or Bottom-Up Approach and Which is Best?

<discussion ref="http://www.ebizq.net/blogs/ebizq_forum/2009/06/are-organizations-developing-bpm-solutions-from-a-top-down-or-bottom-up-approach-and-which-is-best.php" />

From my recommendations for building enterprise BPM systems

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.

Thanks,
AS