Enterprise patterns: PEAS - example and technique

This post is an example of introduction a PEAS-architected platform (see http://improving-bpm-systems.blogspot.com/2011/04/enterprise-patterns-peas.html). IN this example, BPM was used as a technique to reveal  the platform.

The situation:
An organisation (which printed 30 mil pages per year) had about 40 publishing tools. The attempt to replace them by a common tool has failed after 2 years of heated debates: each user was saying that my publishing processes are unique and my tool is the best for me. It was impossible to reach an agreement.

The actions taken:
1) we, enterprise architects, asked the users to bring their business processes (diagrams, of course)
2) we found that those diagrams were impossible to compare - they were prepared in different ways
3) we remodelled all of those processes with the same modelling methodology
4) we demonstrated that all users use the same services with slightly different processes (sometimes just an order of service invocations)  - see examples below.

5) and even all their processes fitted to the same generic process

The results:
1) everyone has agreed that a tool with all identified services and a capability to orchestrate them (i.e. process engine) would be sufficient for the whole organisation
2) a common tool was selected and implemented as a platform
3) a single centre of expertise is developing publishing solutions for all departments

Thanks,
AS

Towards "paperless" or "digital" or "less paper" way of working

Just a few slides from the EA + BPM + SOA + ECM point of view..

Thanks,
AS

How #BPM can help to a broken banking transaction

Yesterday, I made (via the "ebanking" interface) a transfer from my USD account (or sub-account) to my CHF account (or sub-account). Such a transfer is an internal transaction and it is executed immediately during normal working days.

As yesterday was Sunday then this transaction was postponed to Monday. At 7:30 AM on Monday I noticed that my USD account was debited at 4:14 AM, but my CHF account was not credited yet. So, money got lost in this internal banking transaction. The Bank's helpdesk told me that my transaction was correct, a ticket is open and I will be called back as the ticket is closed.

A 11:10 AM, with another login to the ebanking, I found that the money has arrived to the CHF account at 8:14 AM. I got no call but only an e-mail confirming the closure of the ticket at 8:50 AM.

Of course, an error situation may occur in any system. It is important to handle errors correctly. The right use of BPM can help with this:

• a process informs the user about the SLA
• a process detects and classifys error situations
• a process creates a ticket for the support team responsible for this error situation
• a process communicates an abnormal situation to the client (if the SLA is broken)
• a process may have a a small "side" sub-process to handle errors (as seen at the robotic manufacturing)

More details are in my book (www.samarin.biz/book).

Thanks,
AS

Linking business strategy and IT strategy

This post is a continuation of "Writing IT strategy - From business priorities to the planning of IT actions".

The main picture from the previous post is extended to explicitly link move concepts (business strategic objectives, business initiatives, business capabilities, IT capabilities (generic supply), IT tools (specific supply) and IT programmes.

The logic of linking is the following:

1. each business strategic objective has its own corporate priority and is based on one or few business initiatives;
2. each business initiative has its own corporate priority derived from business strategic objective;
3. each business initiative requires a particular level of maturity of some existing or new business capabilities;
4. each business capability has its own current level of maturity (can be determined by experts) and the requested level of maturity (so a gap can be identified);
5. particular level of maturity for each business capability depends on a particular level of maturity of some existing or new IT capabilities;
6. each IT capability has its own current level of maturity (can be determined by experts) and requested level of maturity (so a gap can be identified);
7. each IT tool contributes into one or many IT capabilities;
8. each IT tool has its own current level of maturity (can be determined by experts) and requested level of maturity (so a gap can be identified);
9. each programme implements one or few IT tools, and
10. priorities of programmes are defined by the contribution into business priorities.

This is a possible way to "...setting out your logic about a choice in advance..." as recommended in "Strategy Is All About Practice".

Those explicit links can help you to find leverage points (thanks to Ivo @kvistgaard for "a strategy is a choice of leverage points"; see also http://www.thwink.org/sustain/glossary/LeveragePoint.htm) so you can do more with less.

Keeps the links systematically updated (especially after compelting IT projects) and watch for new leverage points. A strategy adjustment and validation becomes a routine on-going activity during its implementation (like functioning of the GPS navigator).

Thanks,
AS

Quick delivery of solutions via a PEAS-architected platform - mini-projects

This is a continuation of the post Quick delivery of solutions via a PEAS-architected platform" to describe functioning of mini-projects.

Roles within mini-projects (are taken from the DAD book)

A stakeholder is someone who is materially impacted by the outcome of the solution. In this regard, the stakeholder is clearly more than an end user.

The team lead (TL) is a servant-leader to the team, creating and maintaining the conditions that allow the team to be successful.

The product owner (PO) is the one individual on the team who speaks as the “one voice of the customer.” She represents the needs and desires of the stakeholder community to the delivery team.

The architecture owner (AO) is the person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design.

The role of team member (TM) focuses on producing the actual solution for stakeholders.

Solution elaboration

The preferable way for implementing solutions is assembling them from standard components available in the platform. Components are of the following types: Off-the-shelf functional extensions, e.g.

• plug-ins 
• Data structures and reports
• Documents and their metadata 
• Filing plans 
• Collaboration utilities (calendar, news, issues, etc.) 
• Business rules Roles and permissions 
• Processes (or workflows) 
• Tasks 
• Forms 
• Events and notifications 
• Layouts and presentations 
• KPIs 
• Audit trails 
• etc. 

The whole decomposition of a solution into components is also approved by the AO.

All components are versioned through their life-cycle. Component’s life-cycle is as usual: design v1, design v2, implementation v3, implementation v4, design v5, and so on. Versions of components can be produced by TMs with the help of secondary roles.

The last design version (i.e. before implementation) of a component must be approved by the AO.

The last implementation version (i.e. production) of a component must be validated by the PO with the help of stakeholders. TM proactively consults the PO about all components.

Thus the solution evolves as all its components are elaborated and a version of a solution is a snapshot of current versions of all its components. The PO with the help of stakeholders approves a production version of a solution. Each solution may have several production versions; in some case they may co-exist (i.e. overlap in time).

Some intermediate versions of the solution are actually prototypes which are throwable (« jetable » in French) by definition.

Time-boxing delivery

Mini-projects operate in a typical agile and goal-based iterative (like PDCA) way:

• Plan deliverables (a deliverable is a particular version of a component) for the current iteration. 
• Implement (do) selected deliverables. 
• Validate (check) completed deliverables with the product owner. 
• Act upon the feedback from the team. 

Thanks,
AS

#entarch was mentioned in Davos at WEF

From  http://www3.weforum.org/docs/EU11/WEF_EU11_FutureofGovernment_Report.pdf

An Enterprise Architectural Approach. e-Government may be thought of as a complex socio-economic and
human-machine system, which has begun to be explored and developed in recent years with the use of the Enterprise Architecture (EA) methodology. This approach encompasses a generalized representation of the subject domain structure and the subsequent formation and use of the principles and guidelines that define the system architecture development management over time.

One of the important advantages of this architectural method is the availability of tools that allow a government (or any organization) to synchronize a complex system development strategy with opportunities carried by ICT.

Thanks,
AS

You have one of the top 1% most viewed LinkedIn profiles for 2012

Thanks,
AS