Enterprise Architecture / Overview / Cloud Architecture Patterns

In the context of using a SOA strategy for eBusiness transformation, bridging the gap and understanding how different architect domains work together with business is key when modelling an enterprise initiative as per the following excerpt on SOA implementation from Oracle OTN.

"Enterprise Architecture (EA) and Solution Architecture (SA) are often seen as different practices where EA is more concerned about the 'why' or the 'what' and SA is more about the 'How'. In reality EA and SA are facets of the same business function; architecture, where they both work together to to effectively build an architectural landscape. It's about optimising the use of resources to fulfil business needs in accordance with the priorities of the organisation. There are many challenges to building an efficient landscape, which is typically based on Service Oriented Architecture (SOA).

Involving EA in the development of projects and in change management is the best way of driving the development of an SOA. Clearly communicating the impact of each decision to the organisation quickly makes it obvious that sharing services, investing in reusable components, and always reusing before deploying-in short managing the IT landscape consistently across business unit boundaries-provides the most benefits.


Architectural tooling aside, a common topic which always comes up is whether a "top down" or "bottom up" approach is best when designing and constructing architectural models?, the simple answer is "It Depends". Broadly speaking from an EA point of view top down may be preferred, or specifically a domain architect (i.e. solution or information architect) the bottom up may be best. Another way to look at it based on industry perception "Future State" = Down, "Current State" = Up. 

In many cases the above may stand true but not always? Say for instance there is a company wide SOA initiative where the enterprise wants to ensure the SOA benefits are realised across as many business and service areas as possible. For this scenario to determine an appropriate Services Definition Specification, Top Down & Bottom Up (Both) may be the answer. It depends where the viewpoint is taken from and end objective. (i.e EA - strategic or SA - operational).

From my experience a bottom up approach is attractive as it reduces risk and initial cost to implement is lower for a SOA initiative, for complex current state environments this is can be attractive where change happens incrementally in an agile manner and results are delivered sooner which eases the pathway for future transformation.

In short the approach for top down or bottom up will vary depending in what you want to achieve and the best way to get there. In the case of future state full platform replace, then whole approach changes. The SOA journey can vary depending on enterprise complexity and its level of service orientation as shown below, (Diagram ref: Frost & Sullivan) (Ref: Mulesoft for further insight to implementation of SOA in an agile manner)


In the above context modelling enterprise architecture is all about providing a coherent design, good aesthetics and effective use of pre-designed patterns which can be used and adapted for different scenarios. From a solutions architecture perspective its more about the how and what is used to obtain the end business objective. For cloud services the use of industry Architecture Patterns from cloud service providers or standards based sources are a good starting point.

The following steps as referenced by Oracle OTN reflect these attributes which is consistent with my experience around implementing a SOA initiative i.e.
    1. Model the Business Architecture with the Business Users and Business Analysts
    2. Specify Design Patterns for Each Shared Service
    3. Evaluate Different Options with Architecture Analyses
    4. Present the Architecture and Its Benefits to Decision-Makers
    5. Describe the Gaps in Terms of Business Impact
There are a number of commercial / open source architecture modelling tools and frameworks available, I take a vendor agnostic view and use The Open Group Archimate and TOGAF respectively, however from a modelling perspective BizzDesign does stand out as it is based on Archimate and is closely aligned with TOGAF framework. This approach gives a strong foundation which can be applied universally across the architecture modelling domain in conjunction with best practice approach as outlined below. 


In order to show good aesthetics through the use of colour and uniformity, at the most basic level, the following diagram shows the underlying structure for an architectural design for a manually (actor) operated business service using an application supported on infrastructure as indicated.

Applying sound design principles it is easy to identify the active, behavioural and passive elements through separation of behaviour and structure elements where blue elements in the figure represent the active structure ('who') and the yellow elements represent the behavioural aspects of the 'who' elements. The passive elements are shown in green. The pattern style and element relations are repeated across different layers as indicated.

Patterns & Simplification

The use of design patterns is an accepted method to implement a particular function or deployment scenario which is consistent with industry practice. The starting point can be varied depending on how the design is modelled (i.e. level of abstraction), the architecture vision and IT operational landscape.

By using a basic 'T1 Pattern: A Database' as an example, the following diagrams show how different views can be generated from the primary pattern for a range of database deployment scenarios listed below, these also help simplify translation and communication with relevant stakeholders.

  1. Full
  2. No Hardware Details
  3. No Hardware Details & Interfaces
  4. No Hardware Details, Interfaces & Internal Behaviour
  5. Using Abstraction
Scenario 1: DB T1 Pattern Deployment - Full

Scenario 2: DB T1 Pattern Deployment - No Hardware Details

Scenario 3: DB T1 Pattern Deployment - No Hardware Details or Interfaces

Scenario 4: DB T1 Pattern Deployment - No Hardware Details, Interfaces or Internal Behaviour

Scenario 5: DB T1 Pattern Deployment - Using Device Abstraction