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