#entarch basics in "for dummies" style

A fragment from a forthcoming article.

Why Enterprise Architecture? – To take right decisions on evolution

Any enterprise comprises many interrelated parts. Many people work for an enterprise; they must be managed; raw materials must be supplied in time; final products must be delivered as planned; enterprise’s goals must be achieved. All of those parts must be coordinated to work together as one whole. This is no easy because of the natural complexity as there are many interrelated parts with many unknown dependencies between them. Changing of an enterprise to work better, faster and cheaper is a challenge, because the complexity of the future enterprise is unexplored yet. That complexity leads to the high risk of uncertainty in changes.

The world experience shows that architecture is the way to reduce undesired complexity of a system (please, note that any enterprise is a system). Architecture shows in a simple manner the most important parts of a system and relationships between them. The understanding of them enables the evolution of the system as one whole.

The popular example of the architecture concept is civil architecture. A customer contacts a civil architect to present to the customer a solution (in some kind of visual format, e.g. a drawing or a scale model, because the aesthetics are often very important). After approval by the customer, the civil architect works with a general contractor. Figure below shows that an architect is a person who translates a customer’s requirements into a viable plan and guides others in its execution.

Architect works with the both customer and general constructor

Architecture of a small enterprise is comparable with the architecture of a separate building; architecture of a big and medium enterprise should be compared with the urban or city planning. The latter requires thinking about the water, sewer, electricity, and transportation infrastructures between buildings or quarters of a city. An enterprise architect, like a city planner, both frames the city-wide design, and formulates plans for the development of urban and suburban areas.

Enterprise Architecture (EA) [http://www.gartner.com/it-glossary/enterprise-architecture-ea/] is a discipline for proactively and holistically leading enterprise responses to disruptive external forces. EA creates and delivers the actionable knowledge about an enterprise. This knowledge facilitates the enterprise evolution toward desired business vision and outcomes.

How does EA operate? – Facilitating changes

Does an enterprise or a plan behave like “house of cards” in case of changes? Do people endlessly discuss potential changes without coming to a logical conclusion? Do unilateral changes in one department cause problems in other departments? If yes for any of those questions then somebody should anticipate and facilitate the changes.

EA provides: 1) understanding of “operations”, i.e. daily work of the enterprise, and 2) rationale for “transformation”, i.e. changes of the enterprise. What is “transformation” today becomes “operations” tomorrow. The both are equally important and must be considered together.

EA is involved into all change-centric processes as shown in the table below.

Change-centric process	EA acts as	Added value
bottom-up, e.g. business as usual, continual improvements	a guardian of the consistency and integrity	EA estimates the effect (positive or negative) of proposed changes
top-down, e.g. strategy, transformations	a governor to take into account the complexity and impacts	EA finds leverage points (places which bring the biggest improvements)
change-execution, e.g. strategy execution or program implementation	a guide to lead to a desired outcome	EA brings agility, flexibility and transparency

EA makes the knowledge actionable in the change-centric processes. A few examples of typical use of EA will be discussed in the article in more details.

What EA uses? – Artefacts and models

Changes (as a trip to an unknown territory) should not follow the popular “go there – do not know where, bring it – do not know what”. A good trip requires proper instruments, including a map and GPS navigator. EA provides all of them.

EA identifies and describes various constituent parts of an enterprise-as-a-system. Those parts are called artefacts. Typical artefacts are: operational objects, goals, business processes, roles, rules, locations, documents, tools, etc. EA links them in various models (e.g. organisational structure connects organisational units, roles, and people). Models formalise as knowledge the relationships between artefacts. Thus models make this knowledge actionable.

EA establishes rules for changing those artefacts and models as architectural principles, templates, techniques, patterns, and standards. At the same time, EA does not own those artefacts and models. They are owned by various people from the enterprise – stakeholders, CEO, COO, CIO, business process owners, line managers, etc. EA contributes to human capacity by helping those people to understand, create, arrange, interrelate, use, and evolve their artefacts and models.

Variations of architects

Basic type of architect	Primary customer	Plan	Executors of the plan	Comments
Solution architect	Project owner	Architecture of a solution	A project team	Also known as “architecture owner” in agile projects
IT Infrastructure architect	CIO + EA	Infrastructure improvement / modernization / transformation	Infrastructure unit of the IT department	This plan is usually spread over several projects
IT Application architect	CIO + EA	IT Application portfolio improvement / modernization / transformation	IT demand, IT supply (DEV and OPS) units of the IT department	This plan is usually spread over several projects which blend business and IT improvements
Information & data architect	CIO + EA	Information & data improvement / modernization / transformation	Information (business) and data (IT) units	This plan is usually spread over several projects
Business architect	Ideally: COO + EA; Possible: (depending on the maturity of organisation) CIO+EA	Business processes, organisation improvement / modernisation; strategy execution	Business departments and IT demand units	This plan is usually spread over several projects
Enterprise architect	Ideally: CEO; Possible: (depending on the maturity of organisation) CIO, COO	Strategy execution	Divers teams	See "Evolution of the EA function" at http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-patterns-aga.html

Some combinations:
Enterprise solutions architect – solution architect for enterprise-wide solutions
NNN solution architect – solution architect in the NNN domain, e.g. SharePoint

Architect vs project manager

Architect defines a plan.
Project manager executes the plan with the guidance of the architect (for example, a general constructor can’t change the building’s plan without approval of its architect).

A few definitions

Architecture is a fundamental orderliness (embodied in its components, their relationships to each other and the environment), and the principles governing the design, implementation and evolution, of a system.

System is a functional entity formed by a group of interacting, interrelated or interdependent parts.

Artefact is an entity made by creative human work.

Thanks,
AS

Enterprise patterns: Strategy Implementation Chain (SIC)

The aim of this post is to synthesize some enterprise patterns recently published in this blog to address the practical enterprise need of “strategy implementation”. The arrangement achieved links different #entarch artefacts into some kind of chain of transformations, with its supervision and enabling:

1. from the business objectives to a portfolio of projects (or roadmap); 
2. from the brief initial project specs to a prototype; 
3. from a prototype to a deployable solution (processes and services); 
4. from a deployable solution to a deployed solution (by deciding where to deploy each service, e.g. in-house or in-cloud, IaaS, SaaS, PaaS, etc.); 
5. EA supervision of projects; 
6. platform-enabled agile solutions as an implementation enabler; 
7. melting pot of #entarch+#bizarch+#BPM+#SOA+#ECM+#ITIL+#governance+#strategy as a methodology enabler. 

And resources which describe the parts of the chain.

1. Enterprise pattern “Strategy TO Portfolio” (STOP)

• Writing IT strategy http://improving-bpm-systems.blogspot.com/2011/09/writing-it-strategy.html
• Writing IT strategy - From business priorities to the planning of IT actions http://improving-bpm-systems.blogspot.com/2012/06/writing-it-strategy-from-business.html
• Linking business strategy and IT strategy http://improving-bpm-systems.blogspot.com/2013/02/linking-business-strategy-and-it.html
• Enterprise patterns: Strategy TO Portfolio (STOP) http://improving-bpm-systems.blogspot.com/2013/04/enterprise-patterns-strategy-to.html

2. Modelling of explicit and executable business processes

• presentation http://fr.slideshare.net/samarin/how-to-use-bpmn-for-modelling-business-processes 
• presentation  "#BPM for business analysts: modelling procedure"

  http://www.slideshare.net/samarin/bpm-for-developers

• enterprise pattern “Cloud-Aware Processes and Services” (CAPS) http://improving-bpm-systems.blogspot.com/2011/07/enterprise-patterns-caps.html

3. Relationship between EA, PMO, an SDLC methodology and ITIL

•  http://improving-bpm-systems.blogspot.com/2011/01/relationship-between-ea-pmo-sdlc.html

4. Enterprise pattern “#Cloud-Ready Estimation and Evaluation Procedure” (CREEP)

• http://improving-bpm-systems.blogspot.com/2011/12/enterprise-pattern-cloud-ready.html

5. Relationships between EA and PMO

• http://improving-bpm-systems.blogspot.com/2011/01/relationships-between-ea-and-pmo.html

6. Enterprise pattern “Platform-Enabled Agile Solutions” (PEAS)

•  Enterprise patterns: PEAS http://improving-bpm-systems.blogspot.com/2011/04/enterprise-patterns-peas.html
•  Quick delivery of solutions via a PEAS-architected platform http://improving-bpm-systems.blogspot.com/2012/07/delivery-via-peas-architected-platform.html
•  Enterprise patterns: PEAS - example and technique http://improving-bpm-systems.blogspot.com/2013/02/enterprise-patterns-peas-example-and.html
•  Quick delivery of solutions via a PEAS-architected platform - mini-projects http://improving-bpm-systems.blogspot.com/2013/02/quick-delivery-of-solutions-via-peas.html

7. Melting pot

• the book “Improving enterprise business process management systems" http://www.samarin.biz/book
• the blog http://improving-bpm-systems.blogspot.com/

The use of SIC enterprise pattern can help to avoid some risks in EA practice. (The list below is taken from a recent LinkedIn discussion http://www.linkedin.com/groups/What-are-potential-risks-in-36781.S.232446262 )

• Incorrect understanding of business strategy
• Incorrect translating from strategy to architectural design
• Not Balance well on EA aspiration & EA Practicality
• "Waterfall" type of EA, lack of Agile practice - Incremental-ism, Improvement and Iteration.
• Framework or Frameless? How to leverage well?
• "We know what we are doing, even though we've never done it before"
• "We just need a tool"
• No focus on delivering quantifiable value
• Too focused on IT
• "Modeling the Universe"
• "Let’s collect data and see what we find"
• EA Dept hoarding information
• Unable to articulate the value proposition of EA
• Unable to communicate effectively with stakeholders
• Unable to execute in an appropriate risk management approach that matches effort (investment) with return

Thanks,
AS

Enterprise patterns: Strategy To Executable Portfolio (STEP)

This pattern is based on previous blog posts about linking business priorities and IT portfolio of projects - http://improving-bpm-systems.blogspot.com/search/label/IT%20strategy .

Considering that at present the intended strategy is only a part of the realised strategy, it is necessary to take into account emergent strategy as quick as possible.  Developing a strategy for 3 years and and reviewing it only once (mid-term review) is not sufficient. Strategy and related portfolio should be changed more often.

Another typical situation is "...strategy clarification, illumination ... " which is carried out after the approval of the strategy. So, such a strategy may be not "implemetable" at all.

The explicit linking between business priorities and IT projects (see illustration below from http://improving-bpm-systems.blogspot.com/2013/02/linking-business-strategy-and-it.html)

1. guarantees implementation of the strategy, 
2. simplifies the strategy review and 
3. changes such a review into routine activity. 

Thanks,
 AS

First #entarch works?

Mentioning of #entarch work (urbanisme in French) is found on a stone document from Punique Carthage dated at 3rd century (probably) BC.

A description in French is below.

Thanks,

AS

Architects are responsible for HOW thus capability of WHAT

Many recent discussions were talking about WHY, WHAT, and HOW as outputs of architectural work.   I already blogged about dependencies / linking between them (see http://improving-bpm-systems.blogspot.com/2011/02/explaining-ea-business-architecture_19.html ).

In this post, I would like to outline who is responsible for WHY, WHAT and HOW. But, at first, let go back to basics and define "architect".  My terminology (www.samarin.biz/terminology), says that, in the broadest sense, an architect is a person who translates a customer’s requirements into a viable plan and guides others in its execution.

Let us look at civil architecture. In each construction project there are three distinct roles: a customer (an individual, or an enterprise), a civil architect (a licensed individual who leads a team in the planning and design of buildings, and participates in the oversight of building construction) and a general contractor (a company which constructs buildings).

A customer contacts a civil architect who presents to the customer a solution (in some kind of visual format, e.g. a drawing or a scale model, because the aesthetics are often very important). After some possible reworking followed by acceptance of the final solution, the civil architect is empowered by the customer to guarantee a good means of construction. The civil architect selects a general contractor and the civil architect works with a foreman – an experienced professional who is in charge of organising the overall construction, including the construction crew.

The separation of duties between these roles is very important – a civil architect and a general contractor are different individuals or companies (by obligation, at least in some countries). Such a separation helps to achieve the appropriate control and quality of the results. Also, it is interesting to note that there is no explicit project manager role per se – each role has to carry out some “project management” duties. For example, a foreman is actually a project manager on the side of the general constructor (and has usually arrived in a management position after experience as a construction worker and not as a professional project manager). 

In the case of IT projects these roles could be mapped in the following way: the “customer” is a business unit, the “architect” is a small group of agreed minds (i.e. the architecture team) which translates the customer’s requirements into a viable plan and guides the execution of that plan, and the “general constructor” is an internal IT development and infrastructure unit (with the potential of outsourcing).

WHY is given as the client's intention, and it is usually implicit. A good architect must make this WHY explicit by asking right questions.

WHAT is given as the client's ideas, but neither in details nor final (for example, some client's ideas may be just impossible because of some rules and laws). The architect must explicitly define WHAT will be produced.

One definition of WHAT (for the client) has to demonstrate that HOW that WHAT is able to satisfy  the client's WHY. The architect must proof that WHAT is not just a nomenclature with smaller WHATs but how those smaller WHATs are properly structured (and properly "work" together) to deliver the requested capability (ability to address the client's WHY). Such a definition is HOW-capability.

(Remember that capability is a proven possession of characteristics required to perform a particular service with a particular results and with required performance. The key words are: "proven" and "performance".)

Another definition of WHAT, which must be prepared by the architect, is HOW-feasibility which is dedicated for the builders. It is usually a blueprint. And the blueprint is just a beginning. The actual construction should be monitored, supervised and guided to guarantee that the final product does corresponds the blueprint.

So the architect is responsible for HOW because he/she has to proof & guarantee the future performance of WHAT.

Of course, architecting modern information systems is more complex that city planning. Information systems are evolving, new technologies are disrupting, new business needs are emerging, services are re-used, processes are improved, etc. At the same time,  the potentials of proper architecture are huge (for example, http://improving-bpm-systems.blogspot.com/2012/11/an-example-of-entarch-contributing-to.html).

Thanks,
AS

Result-Based Logical Framework

Idea of results chain... Outputs -> Outcome -> Impact.

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

#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

An example of #entarch contributing to a business strategy

"The aim of this Brief is to outline how the coherent use of several existing information technologies can significantly accelerate the achievement of the vision stated in the Bank’s Long-Term Strategy (LTS)."

UNIQUE OPPORTUNITY FOR AFRICA: ARCHITECTING THE SYNERGY BETWEEN EXISTING INFORMATION TECHNOLOGIES

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

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

EA view on Enterprise Risk Management (ERM) platform

In many cases, it is impossible to find a single ERM product which spans all business areas to be covers by ERM. So, it requires building an internal ERM platform on top of which different ERM-related applications will be built (following the PEAS enterprise pattern – see http://improving-bpm-systems.blogspot.com/2011/04/enterprise-patterns-peas.html ).

Business architecture view

Risk must be carefully monitored (through data collection), evaluated and acted upon. This means (see also the illustration below):

1. Enterprise business functions should be enriched to generate the risk-related data.
2. Those risk-related data need to be collected at the enterprise data warehouse together with other business data.
3. Some business processes need to be updated to embed risk-related activities.
4. A set of risk-related rules, logic and risk-related knowledge should be able to use the risk-related and other business data to detect acceptable limits of risk as well as interdependencies and correlations between different risks.
5. Some business processes for risk mitigation maybe automatically activated.
6. A lot of risk-related indicators, alerts should be available in the form of dashboards and reports available for different staff members.
7. Staff members should be able to initiate business processes based on the observed risk-related information.

Business-generic capabilities involved

The following business-generic capabilities are involved in the ERM platform:

• Management by processes
• Efficient data gathering channels
• Single version of truth for data
• Ingesting (into the data warehouse) of external information
• Efficient dissemination channels
• Effortless collaboration within groups / communities of practices
• Formalized business logic

Supremacy of management by processes

Managing any work by processes is the key business capability with allows to address the risk-related issues in a proactive manner. The risk is strongly related to how the business processes are carried out. By understanding a process (i.e. through being able to simulate it) the business may predict how the risk is changing during the execution of that process. The explicit description of processes permits to add a few “check-points” within any process to examine its risk-related “health”.

Business processes act as a skeleton to which the enterprise adds risk management (as shown on the picture below) – each usual activity is enriched by risk-related monitoring and evaluation.

The risk evaluation may initiate some risk mitigation processes. The risk evaluation may be as complex as necessary, and it may include simulations (e.g. value at risk and stress testing), and the conduct of statistical and scenario analysis.

IT-generic capabilities involved

The following IT-generic capabilities are involved into the ERM platform:

• Enterprise resource planning platform
• Data analytic
• Business process management platform
• Business intelligence platform
• Business rules management platform
• Document management platform
• Corporate portal

Thanks,
AS

Writing IT strategy

The IT strategy development logic is the following:
Business strategy -> business architecture TO-BE -> application + information architectures TO-BE -> technical architecture TO-BE -> IT (or EA) AS-IS -> IT roadmap

Main topics in the IT strategy document are the following:

1. Executive summary (½ page – summary for senior management, e.g. the Board members)
2. Business context (½ page – WHY the major directions in the IT strategy have been taken)
   
   • Strategic directions for the IT as an enabler for the company’s mission and vision
   • Potentials of the IT as a strategic driver for the company’s business
3. IT contribution to business success (1 page - HOW IT capabilities and plans will contribute value to the business or delta in business is reflected by the delta in IT)
4. IT guiding principles (½ page – rationales to guide IT decision making)
5. Assessment of the current state of the IT environment
6. IT Roadmap (WHEN and WHAT to reinforce and build)
7. Etc.

Item 3 is illustrated by the following image:

Ideally, such dependencies can be generated from business processes and applications (i.e. from your EA repository).

In the real situation this illustration may become rather complex, so some techniques for better understanding can be necessary. For example, the selection of a rectangular highlights all connected rectangulars and links, as shown below:

And the final advise: be careful with arrows - people may interpret them differently.

Thanks,
AS

Relationship between #BPM and #SDLC and Software Engineering (SE)

In my experience, BPM and SE are very natural friends (with the help from SOA, EA and BA) which work well together within a proper architecture.

Some basics: Any complex system is a dynamic set of artefacts (or building blocks?), e.g. in case of a typical business 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)

So, BPM (with the help from BA, see http://improving-bpm-systems.blogspot.com/2011/02/explaining-ea-business-architecture.html) can derive the artefacts. And SE is responsible for creating good services for all artefacts.

Then BPM, EA and SE have to work together to make explicit and executable models. The best example of executable models is executable business processes. Any business process is a relationship between many artefacts: who (roles) is doing what (business objects), when (business events), why (business rules), how (business activities or other processes) and with which results (KPIs). At the same time, such a process is an explicitly-defined coordination of services to create a particular result. So, there is a recursive relationship between services and processes:

• all our processes are services,
• some operations of a service can be implemented as a process,
• a process includes services in its implementation.

This is the base of a modelling procedure (the core of the SE) whose purpose is to analyse a building block (processes or just activities – what is it supposed to do and should it be considered as a whole?) and to synthesize its implementation (how does it carry out its function and should it be considered as a composite?) as the explicit coordination of other building blocks (processes or just activities).

It is an iterative procedure – it can be applied until we only have left indivisible building blocks (i.e. activities). During modelling it is necessary to collect and refine the different artefacts. To avoid getting bogged down in detail it is useful to construct building blocks recursively, like Russian dolls.

Of course, owing to very nature of modelling as a creative problem-solving human activity, each person does it in his/her own way, and for the same subject two different people may produce two different models. The proposed modelling procedure can’t change this, but it does help to uncover the same artefacts.

Mode details are in my book http://www.improving-bpm-systems.com/book

Thanks,
AS

Linkedin: In one word, what is the single largest problem facing #entarch?

A quick statistical analysis of the responses (with some categorization, e.g.” cacophony” -> “chaos” -> “confusion”) in the linkedin discussion "In one word, what is the single largest problem facing Enterprise Architecture?" http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=43593317&gid=36781&commentID=45630743&trk=view_disc

• 373 unique replies from unique people (the first reply is used if not explicitly specified)
• signal to noise ratio is almost 1 to 4

So, a possible resume about the EA status is “immature (discipline, practice, etc.) with problems in many aspects (acceptance, people, tool, definition, etc.) which is requested to deliver results with higher speed”. Maybe executability will help?

Disclose: executability is my choice.

Thanks,
AS

Relationships between Enterprise Architecture (EA, #entarch) and #cloud computing

Big picture

The effective use of cloud computing at the enterprise level is a two-way street:

1. the use of cloud should be architected for the needs and realities of a particular enterprise and
2. the application portfolio, technologies, etc. used in an enterprise should be adapted to achieve the full potentials of cloud computing.

In general, EA deals with a system of systems. In general, those systems are distributed – each of them is an interrelated and interconnected set of business artefacts [events, rules, processes, documents, etc.] and technical artefacts [servers, OSes, databases, storage, applications, etc.] spread over the network. With cloud computing, the network become rather versatile (many zones with different characteristics) and transparent (easy to move some artefacts from one zone of the network to another).

Considering that EA knows all artefacts and (ideally all) relationships between them, EA should also know the impact (implementation time, risks, cost, performance, etc.) of particular allocation of some artefacts into some zones to optimise (easy to create, easy to operate, easy to maintain and easy to evolve) the allocation of all artefacts.

A simple allocation model

Let us consider cloud as a set of the following zone types (they are named using different colours):

1. classic on-premises computing centre – zone type GOLD;
2. on-premises private cloud – zone type ORANGE;
3. off-premises and enterprise-managed private cloud – zone type GREEN;
4. off-premises and service-provider-managed private cloud – zone type BLUE;
5. public cloud zone type (off-premises and service-provider-managed by definition) – zone type VIOLET.

Although, some of these zone types (e.g. the VIOLET one) may never exist in a particular enterprise, all of them are listed for completeness. The BLUE and VIOLET zone types are built with a set of trusted service providers. The term “zone types” is used because an enterprise may have several zones of the same type (e.g. more than one provider for VIOLET zones).

The allocation of artefacts to zone types is governed through a decision framework which provides a set of rules for putting a particular artefact into a particular zone type. See http://improving-bpm-systems.blogspot.com/2011/12/enterprise-pattern-cloud-ready.html

Practically all artefacts may be in any of these zone types. During the continuous virtualisation of technical artefacts, almost all of them may be moved from the GOLD to ORANGE and GREEN zone types and then to the BLUE and VIOLET zone types. Artefacts, like applications, may be transformed before the move or not.

The decision framework takes into account factors such as

• data sensitivity,
• security of data,
• network latency,
• the intensity of use,
• artefact architecture,
• the technologies involved,
• dependencies between services,
• SLAs,
• BCDR requirements,
• the existing zone (including its operating cost and risks),
• the target zone (including its operating cost and risks),
• the cost of moving,
• etc.

Also, the decision framework reflects the business strategy, e.g. an organisation which anticipates a rather aggressive decentralisation shouldn’t promote the use of the ORANGE zone type.

The artefacts (business and technical) mentioned above are actually services which implement related artefacts, and sometimes there is a trivial dependency between business and technical artefacts. For example, business documents (business artefact) are implemented by Enterprise Content Management (ECM) services (technical artefacts) which require a database, file storage, application server, backup, monitoring, etc. (technical artefacts).

Services are useful for building cloud-optimised solutions

Ideally, a cloud-optimised solution is a set of interrelated and interconnected services which are good cloud citizens (or highly cloudable). In reality however, there are still many classic monolithic applications which are actually conglomerates of many potential services and therefore it is not easy to evaluate how cloudable they are. For this reason, any approaches for replacing monolithic applications (existing and/or new) by coordinated sets of services are very welcome. Some of the related concepts are mentioned below.

Services (defined as explicitly-defined and operationally-independent repeatable units of functionality that create a particular result) and, especially, stateless services are the best candidates for clouds (i.e. they are highly cloudable) – just add more instances but be careful about dependencies.

SOA (defined as an architectural approach for constructing software-intensive systems from a set of universally interconnected and interdependent services) is a way of thinking in terms of services (e.g. large, more functional, services are assembled from small, less functional, ones).

Enterprise Service Bus (ESB) is the best way to provide universal connectivity (mentioned in the previous paragraph). But, it is necessary to avoid trying to solve all integration problems with an ESB – see http://www.slideshare.net/samarin/example-use-of-bpm-to-monitor-an-esbcentric-integration

Idempotency (defined by Wikipedia as the property of certain operations to be applied multiple times without changing the result) applied to services helps to build reliable compositions of services – see the IRIS pattern from my book. Recently, the power of idempotency was demonstrated in April’s AWS issue – see http://www.twilio.com/engineering/2011/04/22/why-twilio-wasnt-affected-by-todays-aws-issues/. Also, note that the SAP BIT420 training course has an example of idempotent services.

The functioning of any enterprise is the coordination of many activities (human and automated) – see http://improving-bpm-systems.blogspot.com/2011/02/explaining-ea-business-architecture.html. Considering that the majority of those activities are actually invocations of services, it is possible to say that the functioning of the enterprise is the coordination of many services via different techniques: token-based, rule-based, event-based, data-based, manual-based, etc. If all coordination is made explicit (via BPM), this will provide the necessary information about all static and some dynamic relationships between services.

Typical questions about cloud computing

The following provides a typical list of enterprise-wide concerns relative to cloud computing.

• How can we know if cloud computing is even appropriate for our company?
• Which systems, applications and business processes are the best candidates for cloud outsourcing?
• How can we effectively manage the interrelationships between systems, business processes and data we want to outsource with those that will remain in-house?
• What would be the most effective cloud configuration for our company (private, public, hybrid, community, etc.)?
• How do we protect sensitive agency data in the cloud?
• How do we comply with industry records management requirements in a cloud environment?
• What’s the best way to assess and manage our company’s risk profile in a cloud environment?
• What are the actual costs of our IT operations today? What cost savings can be expected by transitioning to cloud computing?
• How well are our current corporate IT investments performing? What performance improvements are possible in a cloud environment?
• Where do we start? What are the steps to get from where we are today to a cloud environment?

It is clear that the simple allocation model (in which the decision framework is filled by your rules) and the ability to deliver solutions as a set of services will be of considerable help to address systematically those concerns.

Thanks,
AS

Explaining EA: business architecture basics 1

Note: a revised version of these three posts is available at http://www.improving-bpm-systems.com/pubs/Explaining-EA-BA-basics_v7.pdf

The purpose of this post is to provide an explanation about Business Architecture (BA). Informally speaking, BA defines how work gets done within an enterprise. How work gets done is, of course, not completely unknown, but the knowledge is diffused throughout different instructions, strategic papers, reports, e-mails and in peoples’ heads. The aim of BA is to make this knowledge explicit, i.e. formal, externalized and operational, so it can be used for decision making, operating control, daily work, knowledge transfer, etc.

First, it is necessary to achieve a common understanding about certain concepts (and the relationships between them) used for constructing BA. Examples of such concepts are: function, process, service, capability, etc. These concepts are used to provide different views of the enterprise. It is important that these views are coherent and that interdependencies between them are explicit.

BA is a part of Enterprise Architecture (EA), and usually BA is the least understood / developed / implemented part of EA.

1 General

An enterprise creates a result which has value to a customer who pays for this result. The enterprise acts as a provider (supply-side) and the customer acts as a consumer (demand-side).

There is a (business) transaction between the provider and the consumer. From the point of view of the consumer (the outside-in view) the transaction is bounded by the pair “request and result”, e.g. from making an order to receiving goods. From the point of view of the provider (the inside-out view) the transaction is a set of several distinct activities (or units of work) which function together in a logical and coordinated manner to satisfy / delight the consumer. These activities are carried out in response to the consumer’s request which is an external business event for the provider.

2 Business functions

The collection of an enterprise’s activities serves as the foundation for the discovery of business functions (functions deliver identifiable changes to assets). Each function is an abstract and self-contained grouping of activities that collectively satisfy a specific operational purpose (e.g. management of relationships with partners). Functions are unique within the enterprise and should not be repeated. Some functions can be decomposed into smaller groups of activities, and thus the function architecture has a hierarchical structure. The structure of functions is not always the same as that of the organisation chart; in many cases, some organisational units can span several functions. Furthermore, organization charts may change while the function architecture does not.

A business function typically has the suffix "management" in its name (e.g. "Customer Relationship Management"), but it can also be a noun (e.g. "Marketing"); usually, function name specifies something that is performed continuously. Some examples of business functions (from http://www-935.ibm.com/services/us/imc/pdf/g510-6163-component-business-models.pdf) are given below.

The functional view emphasizes WHAT the whole enterprise does to deliver value to the customer (without the organizational, application, and process constraints). Usually, the hierarchical structure of business functions is very static (with a low rate of change). Meanwhile, business processes can change more frequently as a result of business process improvement or re-engineering initiatives.
The function architecture can be used in a number of ways:

1. to understand how organisational units are supporting each function and to identify instances where a function is supported by several organisational units (or is not supported by any organisational unit);
2. to reveal how functions are currently automated, including occurrences of where there is an overly complex use of applications (e.g. multiple applications) and when there is no automation of functions in place;
3. to understand how assets (information) flow between functions, and to map out which functions produce information, which function(s) consume information and where there is no clear understanding of information movement and ownership;
4. to clarify how business processes can be constructed;
5. to determine which business performance metrics should be used.
   In some senses, functions are the players in a team (i.e. the enterprise), but it is not clear how they are going to play together.

3 Value-streams

The collective use of activities to satisfy a customer’s request leads to the notion of a value-stream which is an end-to-end collection of those activities (both value-added and non-value-added) currently required by an enterprise to create a result for a customer. Value-streams are named according to an initiating event and its result. A few examples of value streams are provided below (mainly from www.enterprisebusinessarchitecture.com):

Prospect-to-Customer	Order-to-Cash (order fulfilment process)
Manufacturing-to-Distribution (manufacturing process)	Request-to-Service
Design-to-Build	Build-to-Order
Build-to-Stock	Insight-to-Strategy
Idea-to-Concept	Concept-to-Product
Product-to-Launch	Initiative-to-Results
Relationship-to-Partnership	Forecast-to-Plan
Requisition-to-Payables (procurement process)	Resource availability-to-Consumption
Acquisition-to-Obsolescence	Financial close-to-Reporting
Recruitment-to-Retirement	Awareness-to-Prevention

Value-streams are directly linked to the enterprise’s aspirations – its vision and related “ends” chain (see http://www.omg.org/spec/BMM/): desired results, goals and objectives. Ideally, each value-stream should align with at least one long-range objective and its business performance metrics [key performance indicators (KPIs)]. For example, one objective of the success of the “Order-to-Cash” value-stream may be measured as “96% of orders delivered within 3 days”. If this value-stream’s actual performance is delivering only “90% of orders within 3 days” then a corrective action should be taken (e.g. a new strategic initiative is developed and its priority determined).

In addition to the reason WHY a value-stream exists, related to each value-stream there is an explicit HOW the desired results are achieved. Looking inside a value-steam reveals that there may be a few “integrated components” (or business cases – business transactions between a consumer and a provider). Usually, one of the “integrated components” is the main transaction which does the job and the others are collections of supporting/housekeeping activities. For example, “Order-to-Cash” includes “Fulfil order” (main), “Change order” (for cancellation and modification of an order by the customer), and “Review order” (for the consultation of an order by the customer).

Each “integrated component” is an ordered sequence of acts with applying functions to assets. Such a sequence is the explicit assets flow (called inputs and outputs, or I/O). KPIs and timelines associated with the sequence provide additional execution details (e.g. duration of the process from one point of I/O hand-off to another point). Thus the value-steam view provides the context (without the organisational and application constraints) for its constituent activities, e.g. what timing, level of performance, etc. are necessary to reach the objective of the complete value-stream.

An enterprise consists of a collection of value-streams. Most large enterprises can be broken down into a dozen or more value-streams. The nomenclature of value-streams differs somewhat from one enterprise to another. Within an enterprise, its value-streams are interdependent; a value-stream may rely on the results of other value-streams. An example of this interdependency is the value-chain of an enterprise, i.e. a network of strategically relevant integrated components of value-streams of the enterprise.

Two further posts will cover "Linking WHY, WHAT and HOW" and "Managing the complexity of VEB".

Continue at Explaining EA: business architecture basics 2

Explaining EA: business architecture basics 2

Note: a revised version of these three posts is available at http://www.improving-bpm-systems.com/pubs/Explaining-EA-BA-basics_v7.pdf

Continued from Explaining EA: business architecture basics 1

4 Linking WHY, WHAT and HOW

So, an enterprise’s value-chain and value-streams are the high-level decomposition of the work of the (whole) enterprise into the work of many different activities. In such a decomposition, WHY + WHAT of the whole enterprise should be used to define WHY + WHAT of each activity. The glue between them is HOW. Let’s look at a fictitious scenario.

Stakeholders:
OK, your business model looks good. Now tell us about the operating model.

Future CEO:
Our business model is the WHY for our operating model. The latter starts by showing the relationships between the enterprise and its partners (suppliers, providers, customers, etc.) from the economic ecosystem. Within the enterprise we have identified 4 aggregations of value-streams: customer-centric (green), strategic-visioning (blue), people-caring (yellow) and business enabling (red), as well as the relationships between them.

The enterprise and related external partners	The enterprise as a set of aggregations of selected value-streams
Example from www.enterprisebusinessarchitecture.com.

We know all our value-streams and their integrated components. Each value-stream is connected to a particular objective. Also, we know our value-chain.

Value-streams	Value-chain
Example from www.enterprisebusinessarchitecture.com.

So, for each value-stream (FUNC1), we know its input WHAT0, its output WHAT1 as well as its operating requirements WHY0.

Stakeholders:
Sounds great. And, can you assure us that FUNC1 is capable of operating as required?

Architect:
The desired performance of FUNC1 is guaranteed by its implementation (HOW1) as the explicit coordination of “smaller” functions. In some way, WHAT1 is decomposed into a set of WHAT2x. WHY0 is decomposed into a set of WHY1x, and FUNC1 is decomposed into a set of FUNC2x. They are all coordinated together. In the illustration below, the coordination is trivial, but in real cases it may be rather complex (e.g. an interaction of activities carried out by several interdependent functional roles).

Stakeholders:
Please continue until all FUNC# become “manageable” activities so that they can be bought, rented, outsourced and easily implemented.

Architect:

This will involve the explicit decomposition of each value-stream to reveal the horizontal (peers) and vertical (subordinated) structure.

... Some time later ...

Architect:
As a result of this decomposition, a directed graph can be obtained (see the figure below). This directed graph is represented as a river basin; it could also be represented as an iceberg in which the value-stream is the tip of the iceberg.

In this graph, nodes (i.e. activities) are connected by edges to show the dependencies between results (i.e. the result of activity C depends on the results of activities I, K, L and B). This means that the result of a particular activity contributes to the result of another activity (which is probably more valuable and thus more expensive). The timing of result generation may be different: some results can be produced in advance and stored for later, some results can be produced on demand and some results can be acquired just before they are needed.

The primary importance of such a graph (called a “value & expenses basin” or “VEB”) is to represent business performance – the business wants to delight the customers (by giving them what they want to pay for) and the shareholders (by creating a profit). As shown in the figure below, different activities contribute differently to the generation of the value (green arrows) and the associated expenses (red arrows). The width of the arrows signifies the relative amount of value or expense.

The VEB should help in the management of an enterprise. It represents a dynamic, actual and contextual contribution of different activities to the value and expenses associated with a particular result. The business can be attentive to different “tributaries” which are

a) the most value-adding,
b) the most wasteful,
c) doing worse than defined by WHY, and
d) doing better than defined by WHY.

Depending on the business needs, such a representation can display a particular instance of value creation or a set of instances (usually over a given period of time).

So, how is a VEB constructed?

A VEB is not a flow of control, an event processing network (EPN) or a PERT diagram. It can be considered as a flow of assets (or a data flow diagram), but this will be just an externally-visible representation of internal mechanisms. Such a representation is good enough for the reactive analysis of behaviour, but is not sufficient for active control and pro-active (predictive) analytics. It is necessary to have a dynamic model which can be used for execution (e.g. simulation) and from which the VEB can be generated.

The set of “internal mechanisms” (as mentioned above) is a superposition of different coordination techniques (token-based, rule-based, event-based, data-based, etc.) as illustrated in the following.

1. An activity from one value-stream (or business process) can obtain some assets (business objects) which belong to another value-stream (or business process). This is pull-like communication, e.g. the “Order-to-Cash” value-stream should know the customer’s address which is maintained by the “Prospect-to-Customer” value-stream.
2. An activity from one value-stream (or business process) can send some assets to another value-stream (or business process). The latter interprets appearing of the assets as an event to be treated. This is push-like communication. Usually, there are three ways in which this treatment can occur:
   • a new instance should be started (e.g. for the manufacture of something) – initiating event;
   • an existing instance, which is waiting for this event, consumes the event and continues its work (e.g. the confirmation of a payment) – solicited event;
   • an existing instance, which does not expect this event, has to react to it – unsolicited event.

In reality, the situation is rather complicated. An enterprise may have several value-streams running in parallel. Some activities can be shared between different value-streams and some value-streams may compete for limited resources. Some activities may be outsourced or insourced, etc. All of these complexities need to be taken into account.

Furthermore, in addition to the activities, there are several other artefacts (see chapter 6) which should be defined explicitly in the model.

Continue at Explaining EA: business architecture basics 3

Explaining EA: business architecture basics 3

Note: a revised version of these three posts is available at http://www.improving-bpm-systems.com/pubs/Explaining-EA-BA-basics_v7.pdf

Continued from Explaining EA: business architecture basics 2

5 Managing the complexity of VEB

The interactions between activities reveal the different relationships between them. In order to manage the complexity, the primary interest of any architecture is to bring structure to those activities and their relationships. There are several techniques (services, capabilities, and processes) which are discussed below.

Activities which are used by a number of other activities (i.e. commonly-used functions which are the result of specialisation) are wrapped as services (which function as some kind of independent building blocks). A service is a consumer-facing formal representation of a self-contained provider’s repeatable set of activities which creates a result for the consumer. (It is considered that there are internal [even within an enterprise] providers and consumers.) It is important that the internal functioning of a service is hidden from its consumers, so that some parts of the enterprise can be changed independently. For example, a “proper” service can be relatively easily outsourced. Services are expressed in terms of expected products, characteristics and delivery options (cost, quality, speed, capacity, geographic location, etc.) – this is the Service Level Agreement (SLA).

Complex services are created by means of the coordination of more simple services and/or activities (in the same way that an orchestra is a coordination of individuals and their actions). In this sense, an enterprise is a mega-service composed of a network of nano-services. Each service is associated with an owner who is responsible for delivering the promised results in all instances in which that service has been requested. That owner has

1. to know/estimate the demand-side needs (the service may have many different consumers who will be using it with different frequencies), and
2. to design/organise/create in advance the supply-side capabilities to ensure those needs are satisfied.

Capability is the proven possession of characteristics required to perform a particular service (to produce a particular result, which may include the required performance). Capability needs to “understand” the mechanics of delivering that service. The mechanics include the resources, skills, policies, powers/authorities, systems, information, other services, etc., as well as the coordination of work within the service.

So, how can one ensure that a service has the required characteristics? There are three options:

1. by contract (“re-active” approach) – acquire a service with the required characteristics, use it, check that its performance is acceptable and replace it if something is wrong with it;
2. by measurement (“active” approach) – implement a service, use it, measure it, improve or re-build it, etc.;
3. by design (“pro-active” approach) – build a service model, run a simulation test, improve the model, build the service, use it, measure it, improve it, etc.

The first option works with some support services, the second option can work satisfactorily with lead services and the third option should be used for core business services. The core business services can’t be outsourced, can’t be bought and must not be “damaged” (otherwise the enterprise may no longer function).

One of the models of the mechanics of delivering a service is a business process – an explicitly-defined coordination of services and/or activities to produce a particular result. The explicit coordination brings several advantages.

• It allows planning and simulation of the behaviour of a service to evaluate its performance. If that service uses other services, then the demand-side needs for those services can also be evaluated.
• It can be made to be executable, thus guiding how work is done.
• It allows control that the actual behaviour of the service matches its intended behaviour, thus pro-actively detecting potential problematic situations.
• It allows the measurement within a service of the dynamics of different characteristics, e.g. valuing, costing, risk, etc.
  

So, there is a structure of services in which some services are composed from others via explicit processes. The use of explicit processes allows the objective definition of the capabilities of composed services.

6 Typology of business architecture artefacts

6.1 Motivation artefacts (why to do what)

Vision and related “ends” chain – desired result, goals, objectives

Mission and related “means” chain – course of action, strategy, tactic/projects

6.2 Value and profit proposition artefacts (what to do)

Value, value-streams, value-chain, value creation, value system, TOM?

Products or assets (tangible and intangible)

6.3 Organisation artefacts (who is doing)

Organisation structure

Governance structure

Supplier, providers, customers, and other partners

6.4 Execution artefacts (how to do what)

Process, Services, Functions

6.5 Knowledge/information artefacts (with what resources)

Terms, facts, rules, policies, etc.

6.6 Performance artefacts (how well to do what)

Capabilities, KPIs

Relationship between EA, PMO, an SDLC methodology and ITIL

Continue of the post “Relationships between EA and PMO”.

For the moment, I don’t discuss the “local” SDLC methodology. It is considered that it translates (as a project) a request for a business solution into a set of interdependent services. Some of those services are new; some of those services are new versions of existing services. The main steps of such a translation are:

• Architect a solution as a set of services (BPM, SOA, etc. is are used for quick prototyping to understand WHY and WHAT for each service as well as the effect on the whole enterprise environment)
• Design each service (supply HOW for that service – buy, build, rent, outsource)
• Deploy each service (of course, provide the ruthless monitoring for each service before deployment)

So, it is necessary to guarantee that newly created services or versions of services will be the good ITIL citizens. For this reason, many of ITIL processes have to be “invoked” during projects as shown in figure below.

Thanks,
AS