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

Coordination techniques in BPM, Social, ACM, etc.

Considering the definition of a process as “explicitly-defined coordination of services to create a particular result” this post shows how some explicit coordination techniques (rows) are employed by different “methodologies”  (columns) for managing the business by processes.

	Classic WF	Classic BPM	ACM	Social NNN	EPN
template-based	++	++	--	--	-+
event-based	-+	+-	+-	-+	++
rule-based	++	++	+-	-+	+-
role-based	++	++	+-	-+	-+
information-based	-+	-+	+-	+-	-+
intelligence-based	-+	-+	-+	+-	--
community-based	--	--	-+	++	--
goal-based	--	--	+-	-+	--
instance-based	--	-+	--	--	--
interprocess (used instance-based)	--	--	--	--	--
managerial (tacit-knowledge-based)	--	-+	--	--	--
resource-based (follow the resource life-cycle)	--	-+	+-	--	--
inter-organisation	--	-+	--	--	--
state-based ??	??	??	??	??	??

A combination of some of them may provide "predictive analytics".

Ideally  – like in the chess game – use must the right combination of coordination techniques in a particular case at the particular moment. But, not all process-centric tools offers all coordination techniques. 

Also a related post about BPM and ACM - http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html.

Thanks,
AS

Writing IT strategy - From business priorities to the planning of IT actions

This post is the continuation of the post "Writing IT strategy" -  http://improving-bpm-systems.blogspot.com/2011/09/writing-it-strategy.html

The explicit dependencies between business-specific initiatives, business-generic needs (or business capabilities), IT-generic capabilities and programs demonstrated in figure below allow to explicitly linking the business priorities with the planning of IT actions. The logic of linking is the following:

1. each business-specific initiative has its own corporate priority;
2. each business-specific initiative requires a particular level of maturity of some existing business-generic needs;
3. each business-generic need has its own current level of maturity (can be determined by experts) and the requested level of maturity (so a gap can be identified);
4. particular level of maturity for each business-generic need depends on a particular level of maturity of some existing IT capabilities;
5. 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);
6. programmes to close gaps are proposed, and
7. priorities of programmes are defined by the contribution into business priorities.

Thanks,

AS

Architecting modern information systems

My course "Architecting modern information systems" (please, see its structure below) is available at slideshare.net.

The class in Tunisia:

 Module 1: Enterprise architecture (EA) http://www.slideshare.net/samarin/architecting-of-modern-information-systems-m1

•  Architecture within an enterprise 

 Module 2: Business architecture http://www.slideshare.net/samarin/architecting-modern-informaiton-systems-m2a and http://www.slideshare.net/samarin/architecting-modern-informaiton-systems-m2a-business-architecture

•  Management by processes 

 Module 3: Application architecture http://www.slideshare.net/samarin/architecting-modern-informaiton-systems-m2b-application-architecture

• Link applications to the business 
• Technologies: BPM, BRM, BEM, BAM 
• SOA, Integration (ESB), Application systems (suites) 

 Module 4: Information architecture http://www.slideshare.net/samarin/architecting-modern-informaiton-systems-m4-information-architecture

• Knowledge management 
• Technologies: ECM, MDM, BI, risk management 

Module 5: Technology architecture

• Flexibility systems 
• Security considerations 
• Virtualisation 

 Module 6: Modern disruptive technologies http://www.slideshare.net/samarin/architecting-modern-informaiton-systems-m6-modern-disruptive-technologies

• Cloud computing 
• Social computing 
• Free and Open Source Software; Open standards 

 Module 7: Essential techniques http://www.slideshare.net/samarin/architecting-modern-informaiton-systems-m7-essential-techniques

• Project management (PMBOK, HERMES)  
• Governance (COBIT)
• Writing the IT strategy

Thanks,
AS

Lettre de remerciement

Enterprise pattern: SITO, extended

Comments to SITO enterprise pattern (see the updated version of it at http://improving-bpm-systems.blogspot.com/2011/10/enterprise-pattern-structuring-it.html ) were that it is too classic. Sure, structuring is the first step to establish the balance between functions and projects.

Next step is how to preserve, enrich and re-use the technical/business knowledge and experience gained in each project. A possible way is to create competence forums which are oriented to deliver business-generic services (or "needs" as they mentioned in http://improving-bpm-systems.blogspot.com/2011/09/writing-it-strategy.html ). Usually, such services are based on several IT-generic services which are mastered in different IT functions.

How those competence forums to be managed to avoid over complication and conflicts of responsibilities? Competence forum is led by the CIO with the help from an informal leader from the participants. For example, the CIO chaired a few initial meetings and then delegates the routine work to the informal leader.

Next step, the IT governance, was already covered in http://improving-bpm-systems.blogspot.com/2011/01/relationships-between-ea-and-pmo.html . Just a small addition to that post:

• EA (or EITA) defines/monitors WHAT should be done (technical coordination of the enterprise IT environment).
• PMO defines/monitors HOW it should be done (administrative coordination of changes in the enterprise IT environment).

Both EA and PMO are top-down and they are supported by bottom-up ITIL (http://improving-bpm-systems.blogspot.com/2011/01/relationship-between-ea-pmo-sdlc.html ). 

Thanks,
AS

Enterprise anti-pattern: Silo-Oriented Virtualisation Anarchy (SOVA)

That was found in the same organisation....

Normally, an organisation of this size should not used more than 2 virtualisation products.

Thanks,
AS

Enterprise pattern: #Cloud-Ready Estimation and Evaluation Procedure (CREEP)

The aim of this post is to consider a systematic procedure for estimation and evaluation of cloudability of an IT service – what type of cloud (GOLD, YELLOW, GREEN, BLUE, VIOLET) is acceptable for a particular IT service and for what cost. Quick reminder re the zone types (from http://improving-bpm-systems.blogspot.com/2011/07/1-relationships-between-enterprise.html ):

• classic within enterprise computing centre – zone type GOLD; 
• within enterprise private cloud – zone type ORANGE; 
• outside enterprise and enterprise-managed private cloud – zone type GREEN; 
• outside enterprise and service-provider-managed private cloud – zone type BLUE; 
• public cloud (outside enterprise and service-provider-managed by definition) – zone type VIOLET. 

The evaluation consists of two parts:
1. ranking of an IT service by several characteristics,

2. decision table for acceptability of cloud solution (actually, what ZONEs are acceptable for this IT service). 

Note: “maybe” means that further investigation is necessary;
Note: more than one column for GREEN, BLUE, and VIOLET can be possible if you work with several providers

Example: SharePoint Extranet

Ranking applied

Decision table applied

Rules for the recommendation :

1. If at least one “NO” then “NO”
2. If no “OK” and some “maybe” and “IaaS/PaaS/SaaS” then “maybe” + “IaaS/PaaS/SaaS”
3. If some “OK” and some “maybe” and “IaaS/PaaS/SaaS” then “OK” + “IaaS/PaaS/SaaS”

Note: CAPEX and OPEX are functions of a service and a zone type.

Resume: 3 zones are not recommended, 2 accepted as SaaS:
1st preference SaaS in BLUE zone; CAPEX = ...  OPEX =... Lead time=....
2nd preference SaaS in GREEN zone; CAPEX =.. OPEX =... Lead time=...

Thanks,
AS