Linkedin: How does architecture ensure system flexibility?

Continue from http://improving-bpm-systems.blogspot.com/2010/01/linkedin-how-does-architecture-ensure.html


A few comments:

RE: <The better question would have been - "How much am I willing to spend to ensure flexibility of my systems?".>

The first consideration – it is known that

• “80 % of software lifecycle costs occur during the maintenance phase”, and
• “80 % of maintenance is due to unmet or unforeseen user requirements; only 20 % is due to bugs or reliability problems”.

These values were reported in 1992 as an average for the IT industry; the current situation for some enterprises is worse – the development and deployment of an application can be only 5 % of the total cost of its ownership. What is also disturbing is that these values are not widely known to many people from the IT industry, and IT staff typically estimate these values completely differently – see below http://www.samarin.biz/misc/EPI-TCO-c.png

The second consideration: A desired level of agility / flexibility may be different in different industries and, moreover, it may change over the time. For this reason, I prefer to talk (see the already mentioned presentation) about “optimal agility”.

RE: < One answer is: by using appropriate design patterns. >
Also architectural principles are useful – my list is the following:

• A few definitions can be useful
• Endorse the “building block” architectural concept from TOGAF
• Avoid modification of shrink-wrapped commercial or freely available software
• Danger of premature optimization
• Avoid the trap of the selection of “top-down” vs. “bottom up”– use the “pinball” style
• Explicit is better than implicit
• The big picture
• Horizontal and vertical coordination
• Long-running processes
• Avoid dispersion of the business logic
• The importance of business events
• Visibility of artefacts
• You may break any principle provided that you master it

RE: < Overall flexibility is a too generic concept to drive an architecture effort.>
As usually, we deal with a system of systems (or even with more “nested” structures) then the architecture of each system should address flexibility in its own way. So, the architecture of the top system of systems may provide “overall flexibility”.

Thanks,
AS

Linkedin: Brainstorming on Adaptability / Flexibility

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=84758&discussionID=11789589&sik=1263141957825&trk=ug_qa_q&goback=.ana_84758_1263141957825_3_1" />


My area is to improve not general, but IS/IT capacity of change, because the latter is the main blocking factor in many organizations. Usually, we do some specific initiatives first and then spread and generalize the experience. I use several techniques:

1. Show the slide 4 from http://www.slideshare.net/samarin/creating-synergy-between-bpm-and-ea-in-an-egovernment-environment to indicate importance of flexibility.
2. Coach the business how to request and test flexibility of different IT products (instead of just compliance to the specs), e.g. a vendor of BPM suite should be asked to implement a simple process and to carry out some changes during the live presentation.
3. Prepare prototypes which demonstrate flexibility.
4. Rescue “rotten” projects.

A recent example – a tender for an MIS for a governmental agency.

• High level of flexibility explicitly required
• Budget 4,5 MCHF
• About 10 offers

Some contenders:

• Classic development – 17 MCHF
• ERP hidden under workflow – 4 MCHF
• BPM-based – 2,5 MCHF

The latter has demonstrated a simple prototype and that helped to win the tender. Of course, to calm down the internal IT department, the winner has to do an extra “feasibility” step -- quickly demonstrate a very advanced prototype, which works at the client’s IT environment.

Thanks,

AS

More details are in my new book “Improving enterprise business process management systems” www.samarin.biz/book

Linkedin: How does architecture ensure system flexibility?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1523&discussionID=10617743&sik=1262950490126&trk=ug_qa_q&goback=.ana_1523_1262950490126_3_1" />

Any complex system is a dynamic set of artefacts (or building blocks), e.g. in case of a BPM system those artefacts are: processes, services, events, data structures, documents, rules, roles, activities, audit trails, KPIs.

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.

My main architectural principles for creating flexible systems:
- All artefacts must be evolved to become digital, external, virtual and components of clouds
- All artefacts must be versionable throughout their lifecycle
- All relationships between these artefacts are modelled explicitly
- All models are made to be executable

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

Thanks,
AS

More details are in my new book “Improving enterprise business process management systems” www.samarin.biz/book

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