Enterprise patterns: PEAS - example CUBE platform

An example of a Corporate Unified Business Execution (CUBE) platform.

This platform is architected from the several components. For each components, a set of capabilities was defined and then best-for-fit COTS products were selected.

See all the blogposts about PEAS pattern - http://improving-bpm-systems.blogspot.ch/search/label/PEAS

See all the blogposts about platforms - http://improving-bpm-systems.blogspot.ch/search/label/%23platform

Thanks,
AS

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

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

Quick delivery of solutions via a PEAS-architected platform

The aim of this post is to outline how to organise the quick delivery of solutions via a platform architected in accordance with the PEAS enterprise pattern.

The business need

Users’ demands are typically numerous, have many overlapping features and will be implemented with different pace (because different users’ units work with different speed). The challenge is to achieve the synergy between different demands and capabilities of the platform. It can be addressed by a proper combination of architecture (PEAS enterprise pattern), governance structure and implementation practices.

Decomposition into several basic functionalities

Vast majority of users’ demands correspond to several basic functionalities or combinations of them. For example, in an ECM-platform such typical functionalities are:

• Information site 
• Collaboration site 
• Workflow 
• Data collection 
• Common storage 
• Business manual (a la wiki)
• Public site 
• Extranet site 
• Integration with Outlook 
• Securing documents 
• Access from iPad 
• Integration with archive 
• Integration with SAP 

Readiness review

Potential projects are in rows and functionalities are in columns. Each project requires some functionalities for its 1st and 2nd parts (phases). Each functionality is at the different level of readiness: green, yellow and red. This allows estimating the readiness for 1st and 2nd parts of each project. The popularity of each functionality can be estimated also.

Governance structure

There are two primary types of activities:

1. On-going and centralised platform governance: evolution of architecture, evolution of features, evolution of solutions, evolution of practices.
2. Rapid implementation of solution as a mini-project – light specifications, quick prototyping, consistent configuration, fast procurement, agile development, and re-use of existing tools and habits.

The platform governance is carried out by an inter-organisational-units coordination committee (Platform Coordination Committee – PLACOCO).

Mini-projects are carried-out by solution architects (business analysts, technical staff, super-users from the business units, etc. - depending on their complexity).

Platform implementation resources (programmers and configurators) are provided by the IT department and by a set of authorised service providers (platform vendor and its authorised partners).

Operational team provides integration and release of solutions into production.

Implementation practices

Implementation practices should be as light as possible without any internal barriers. In any case, we will work with the speed of the users.

1. Users’ demand is understood by the business analyst (BIZAN).
2. If the BIZAN finds that this demand is too complex then it is escalated to the PLACOCO to assign another solution architect (SA) otherwise the BIZAN acts as the SA.
3. The solution dossier is prepared by the SA with the help of other staff members. A prototype is prepared if necessary.
4. If the solution dossier shows that a proposed solution is NOT straightforward (a set of rules to be defined and it can evolve over the time) then the PLACOCO evaluates it and approves any new features/extensions (if necessary).
5. The solution dossier is transferred to the internal pool of platform implementation resources to come up with the resource allocation.
6. If internal resources are not adequate (too busy or/and lack of expertise) then the solutions dossier is escalated to the external pool of platform implementation resources.
7. Mini-project team (including super-users) is formed and it iterates with the users to finalise the solution.
8. Solution is operationalized following the change management process.

Thanks,
AS

Enterprise patterns: PEAS

Related blogposts are available at http://improving-bpm-systems.blogspot.ch/search/label/PEAS and http://improving-bpm-systems.blogspot.bg/search/label/%23platform

I noticed an enterprise pattern which is Platform-Enabled Agile Solutions (PEAS). It is applicable to situation when it is highly desirable to advance with a new enterprise-wide initiative in an incremental way. It means that developing the final user requirements is virtually impossible because the users just do not know exactly what should be built and they prefer to try those news things in real life. As well as the different departments (or target communities) advance with their (obviously different) speed. The classic approach to IT project management – define everything up-front – just does not work.

From the systemic point of view, it is necessary to provide many solutions (SOLs) which have a lot of similar functionality. The provisioning of SOLs should be carried out with the pace of the target community of practice. At each moment of time, each community may have different pace and may need different functionality.

The proposed architecture (see the illustration above) is based on the following considerations:

• The platform must standardise and simplify core elements of future enterprise-wide system. For any elements outside the platform, new opportunities should be explored using agile principles. These twin approaches should be mutually reinforcing: the platform frees up resource to focus on new opportunities while successful agile innovations are rapidly scaled up when incorporated into the platform.
• An agile approach requires coordination at a system level.
• To minimise duplication of effort in solving the same problems, there needs to be system-wide transparency of agile initiatives.
• Existing elements of the platform also need periodic challenge. Transparency, publishing feedback and the results of experiments openly, will help to keep the pressure on the platform for continual improvement as well as short-term cost savings.

In this pattern, technical concerns are decoupled from business concerns. All of those concerns are addressed TOGETHER by the enterprise architecture.

Added later: the following illustration shows that amount of efforts for implementation of solutions (which is proportional to "Functionality" x "Scope span")  is reduced by the platform. Of course, the latter is a "common" good and a decision to build a platform should be taken strategically.

Thanks,
AS