Topic 2 / Post 3 – Application Architecture layer / Service Oriented Application Architecture

January 31, 2016 / Dennis Holinka

Topic 2 – Application Architecture layer

This week's posts go over the Application Architecture layer, the various perspectives, and related reflections in the blog.

Post 3 - Service Oriented Application Architecture

The integration technology of n tier architectures have been evolving over the decade. However, I have been witness to the return of a point to point paradigm that has been recast into a SOA and Nexus of Forces approach because of some much needed standards -at least that is the way it appears to me after 10 years.  It seems that the best architecture ever built has been the Internet with its universal resource locator and its ability to link and integrate any and every page to any other page that may be needed.  The point to point integration was thought to be to tightly coupled and low cohesion in regards to its integration and it was replaced with the advent of EAI and ESB type technologies whose point was to mediate and broker the connections between 2 points so that the many different connections would not have to be rewired when changes to their interfaces and logic needed to be updated.  By intermediating the interfaces, the broker would prevent tight coupling between service points - producer and consumer from being trapped dependently in change crisis.  Therefore, the Service Oriented Architecture (SOA) emerged that made everything a service and the ESB/EAI mediation layer would broker all integrations in and out of the enterprise.  The outside would be brokered by a Service Gateway and the inside by an Integration Platform. 

Figure:  Mediation by Integration Platform (e.g. virtual - EAI, ESB, ETL, SOA Gateway, etc)

http://gemsres.com/story/aug05/121831/bakker-fig1.jpg

http://dotnet.sys-con.com/node/121831/print

But now, more than ever, this approach of using services and integration has become paramount in what amounts to an integration explosion of being able to link every call to any other service in a way that doesn't make the application hard to maintain.  Therefore, we have reverted to standards that allow for mediation to happen by the endpoints themselves.  That is, there is no need to use a central broker based technology to provide the location and service endpoint independence that was the downfall of point to point integrations.  Rather, by building endpoints that have built in mediation technology build in, we can go back to using point to point without all of the pitfalls. 

The technology that has emerged to support SOA and provide this independence is "the general adoption of the WS-* specifications (also called wizees, a set of open Web service standards that are part of the Web Services Architecture), the ESB will become obsolete, and the endpoints will be independent of any central entity responsible for the integration."  When "systems and platforms support the WS-* specifications, the need for a central piece of middleware to supply the major integration tasks could disappear. The different services in such an architecture act more in a peer-to-peer mode, as opposed to the more client-server mode behavior we see in an ESB architecture. Some argue that SOA has the philosophy to expose the endpoints as equal and free members of the IT landscape. Each endpoint is visible and addressable. Endpoints can enforce security or transactions by providing a usage policy (WS-Policy) that contains corresponding assertions."

Figure:  WS-* Standards

http://cdn.infoq.com/statics_s2_20160128-0241u2/resource/articles/ws-standards-wcf-bustamante/en/resources/standardsdiagram.jpg

What does all of this amount to?  To me, a return of point to point or expressed above - peer to peer.  So what does that have to do with the future of application architecture?  It may be that the Nexus of Forces architecture for application architecture needs to become cast as a peer to peer architecture between applications in the app-store integrating as that point between them or as the architecture of strategic micro-services that are orchestrated in a unified ecosystem of service architecture patterns.  It is this architecture that we need to discover, document, and reuse in order to help enterprises compete on Amazon-like features and the growing consumer expectations of a smart user experience that is made up of cloud, data / analytics, mobility, and social event / stream integrations.  No matter how we look at this new application architecture, it is definitely better than where we have been even if it is a remake or an innovation on the old paradigm.

Topic 2 / Post 2 – Application Architecture layer / Enterprise Application Integration

January 31, 2016 / Dennis Holinka

Topic 2 – Application Architecture layer

This week's posts go over the Application Architecture layer, the various perspectives, and related reflections in the blog.

Post 2 - Enterprise Application Integration

Enterprise Application Integration has been around for almost 10 years but the advent of a new architectural paradigm has supercharged and revitalized the comeback of EAI for application architecture.  Gartner expects a paradigm shift into a new architecture it terms the Nexus of Forces.  The nexus of forces combines cloud, social, mobile, and data together to form the new foundation of a modern application architecture.  The view is that application architecture founded upon the use of service oriented architecture (SOA) using web oriented architecture (WOA) protocol approaches (e.g. REST) will form the backbone of the new architecture.  The architecture will utilize micro-services as has been demonstrated by Amazon and Netflix to allow for the ability of application to achieve extreme scale by way of elasticity. 

Figure:  Nexus of Forces on Application Architecture and Cloud First Unified Ecosystem

https://psu.instructure.com/courses/1772177/files/77042509/download?wrap=1



This will have an impact on the way applications are integrated internally but also external to the company.  Many services will be provided and be made available by integrating cloud services which will commoditize many of the existing internal services.  The application architecture will have to be flexible enough to bind dynamically to external and internal service providers while allowing for the architecture to provide dynamically generated data inputs needed by the cloud provider.  Mobility will be affected by the cloud but not in integrating services from internal to external cloud providers but rather at the EAI center of the mobility universe - at the app-store level.  In other words, apps will need to integrate and invoke other apps that are installed and trusted by the mobile user on the mobile device.  This will call for a UI client integration mechanism that will allow for a discovery based integration binding logic between apps while allowing the application to provide data inputs dynamically to the invoked app by way of negotiated invocation integration parameters.  No matter what the integration mechanism is, we know that the 3 / n Tier application architecture will not be satisfactory for the nexus of forces architecture.  Last, the application architecture will require an event based architecture that will allow for events to be subscribed and published which will allow for dynamic integrations between applications and into data services streams and events.  The events and data streams from social and other transactions will make up the nexus.  All of these new patterns will have to architected and blueprinted for reuse by solution architects throughout the enterprise.

Figure:  Event Driven Architecture of the Nexus of Forces

https://psu.instructure.com/courses/1772177/files/77042570/download?wrap=1

 

Topic 2 / Post 1 – Application Architecture layer / Application Architect and related roles

January 31, 2016 / Dennis Holinka

Topic 2 – Application Architecture layer

This week's posts go over the Application Architecture layer, the various perspectives, and related reflections in the blog.

Post 1 - Application Architect and related roles

There is much confusion both in the theory and practice of Application Architecture as to the role distinctions that it plays as compared to Solution Architecture and Software Architecture.  In the readings from Gartner, it has been found that "Enterprises that fail to distinguish SA work from AA work miss opportunities to ensure single project success and multi-project reuse."  The reason for this is best expressed as an automotive analogy on how things ought to work.  In the automotive business, many of the large components of the vehicle are designed and manufactured by automotive component suppliers.  These suppliers are akin to the software architects of critical subsystem components and they rigorously architect and design the subassemblies, even large ones, so that the automotive factory can produce from large subsystem parts that are available in inventory.  Those individual inventoried items are each architected and designed with strict detail as to the focus within each of those components and the interactions of its parts.  Application Architects are akin to automotive supply chain experts at the Auto manufacturers that create sophisticated cataloging and inventorying, rules on which components need to be used under contextual automobile models and manufacturing processes.  The application architects provide the rules for assembly, the categorization of subsystems that work together as larger sets by automobile families, makes, and models.  The Solution Architects are the akin to the robotic and unionized manual labor assemblers whose job it is to assemble the makes and models according to pre-specified families, makes, and models and then assemble customization options as may be tailored on the manufacturing line.   Each role has a special contribution to play in the overall mass production and customization factory. 

Enterprise solutions are very much similar to this approach of considering the overall principles, models, and artifacts for reuse.  It begins with having an Application Architect who is in charge of defining and creating an enterprise based inventory of application subsystem structures for reuse including the buying and/or building of subsystem assemblies.  The application architect specializes in the overall domain viewpoint of application structures across the enterprise and the patterns and solutions sets that repeat themselves throughout the company.

Figure: Application Architect - Application Supply Chain Specialist

http://yourbusiness.azcentral.com/DM-Resize/photos.demandstudios.com/getty/article/129/19/86511693.jpg?w=560&h=560&crop_min=1&webp=1

The Software and System Architect works to define the subsystem assemblies that will be used in multiple contexts by multiple solution architects in the enterprise either by internal architects that are blueprinting for internal building of subsystems or buying by either providing the blueprint or buying an already made subsystem with an existing blueprint design.  The parts architecture design of the internal subsystem is the focus of this architect.

Figure:  Software and/or Systems Architect - Application Subsystem / Assembly Specialist

http://www.islandone.org/MMSG/aasm/fig5-43.gif

The Solutions Architect works to define enterprise solutions from the overall principles, models, and tools provided in inventory or being created in inventory by an application architect.  The solution architect works to provide architectural design blueprints for the solutions and works to reuse the design patterns that the particular project calls for in the project.  The solutions architect acts as a proponent of application architecture reuse given the solution context for the present IT solution.

Figure:  Solution Architect - Application Architecture Intellectual Property Assembler and Re-user

http://previews.123rf.com/images/1971yes/1971yes1306/1971yes130601515/20454429-Disassembled-car-on-a-white-background--Stock-Photo-car-parts.jpg

 

Topic 1 / Post 3 – Stack overview / Stack and Enterprise Architecture - Enterprise Engineering

January 20, 2016 / Dennis Holinka

Topic 1 – Stack overview

This week's posts go over the Stack of Enterprise Architecture, the components that it is composed of, and related reflections in the blog.

Post 3 - Stack and Enterprise Architecture - Enterprise Engineering

EA Stack and the origin of its taxonomy has been some of the questions that architects have asked in this relatively new discipline.  Enterprise Architecting or Enterprise Systems Architecting has emerged as a hybrid art and science in engineering systems.  It has been said that the most complex systems are enterprises and they are the engines of our economy.  It is with that context, that I provide a look into the systems engineering view of enterprise architecture and the related stack that is used to organize its logic.   MIT has provided an product and systems analogy which provides an engineering insight into enterprise architecture.

Figure: Engineering parallels in products & enterprises and relationship of architecture to engineering

It is from analogies such as this, that Enterprise Architecture can be better understood as an attempt to look at the enterprise as a form of system that needs architecting and therefore requires a stack breakdown of its conceptual parts as was described in the our first lesson.  The view provides the logical insight that the architecture is just the beginning and must be carried out in the form of engineering which has parallel analogies in software engineering, product engineering, systems engineering, etc.  in that each of those have architecture modeling activities that carry through into implementations, operations, and support (e.g. engineering).  Many of the architecture views and models created for and in each of the Business, Data, Application, Technology (BDAT) layers of an enterprise is related to the need of providing organizing logic for design and implementation of the enterprise systematic structure (e.g. architecting) but also its operation, support, and maintenance activities (e.g. engineering).  If the enterprise is a system in need of design and implementation, it will require models at each enterprise layer to represent that need.  However, more importantly, it will require models that provide the other aspects of engineering.  It is from this perspective we see several types of models emerging:  application architecture models to represent the business logic automation structure and behavior of the enterprise's design and implementation but also roadmaps which represent the maintenance structure transitions to new structures as you would do for simpler software structures that are aging or becoming deprecated and/or obsolete by time, wear, requirements changes, or competitive forces.  The application architecture roadmaps become guidance to enterprise changes as architectural artifacts to the enterprise change-transition re-engineering to evolve the enterprise because we know from the lesson that the primary purpose of describing the architecture of an enterprise is to improve the effectiveness or efficiency of the business itself.

References: https://esd.mit.edu/symposium/pdfs/papers/nightingale.pdf

Topic 1 / Post 2 – Stack overview / How to begin an Application Architecture

January 20, 2016 / Dennis Holinka

Topic 1 – Stack overview

This week's posts go over the Stack of Enterprise Architecture and the components that it is composed of.  

Post 2 - How to begin an Application Architecture

In EA, it is important to create a systematic approach to the order in which an  architect begins to document and define the application architecture.  It is through modeling, that an architect conveys the organizing logic to the application layer of the business layer.  We know, that the business layer processes are decomposed in requirements which can be used to properly define the application architecture.  Provided below are a few example artifacts followed by a relationship of the linkage between the models and then the creation of the physical application architecture.  Layers in the architecture are broken in conceptual, logical, and physical as to provide increasing detail and elaboration into the model.  The overall process for the meta model for creating an application architecture is as follows:

The Applications Architecture is a collective architecture views which covers at least all of the following artifacts:

1. Business Area Context Diagram

2. Conceptual Application Domain Diagram

3. Logical Application Component Context Diagram

4. Physical Application Component Context Diagram

The application architecture is used to support the desired business and IT capabilities based on the architectural principles, reference models, tools, standards, and guidelines-best-practices as an assessment to identify current landscape of the systems in the enterprise. The technology and product choices, maturity of the application development processes, application architecture frameworks, reference models, skill expertise in a technology domain are important factors in developing the current and target state application architectures.

As I will provide in the next post, we will discuss how enterprise transition architectures for the application architecture as well as enterprise automation architectures for application architecture are all part of documenting the application architecture but for different purposes.

Figure: Business Area Context Diagram [Adapted from Acme Inc]

Figure: Application Component Context Diagram [Adapted from Acme Inc]

Figure: Application Architecture Meta Model [Adapted from Acme Inc]

References:  http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap31.html

Topic 1 / Post 1 – Stack overview / Styles: Layers and the relation to the Stack

January 20, 2016 / Dennis Holinka

Topic 1 – Stack overview

This week's posts go over the Stack of Enterprise Architecture and the components that it is composed of.  

Post 1 - Styles: Layers and the relation to the Stack

The EA Stack overview and its structure are founded in the concept of using Architectural Styles.  Styles are a form of representing lessons from experience in systems design and form the primary elements in defining concepts on which a system's architecture is built.  Styles are used in general  to reflect architectural patterns that consist of decisions and constraints from specific design contexts.  One of the most popular used architectural styles is the Layered Style and it is on this particular style that the EA stack is represented.  Layered architecture style uses ordered layers that are separated in which one layer may obtain services from a layer below.    Specifically, the layers of the Enterprise Information Technology Architecture are separated into four layers in which one layer in abstract, provides a set of services to the layer above.  This is similar to the way virtual machines are layered to have one ordered layer provide services to the one above all the way up to stack.  In this particular example diagram, the layers are placed adjacent to each other in order to convey the ability of each layer able to receive services from them.  There are many layered style architecture models for EA in which the layers are called either BDAT for business, data, application, and technology or BIDAT for Business, Information, Data, and Technology are used.  The point is that it is used to group related functionality for the aggregation of responsibility.  There are two types of layering: strict and relaxed which constrains the way the layers are allowed to communicate.  The diagram presented as part of the course is another way to represent vertical layering in a relaxed manner which allows a layer to communicate within itself and any lower layer.

Diagram: Retrieved from https://psu.instructure.com/courses/1772177/files/77042589/preview

Many architects are familiar with the OSI communications reference model which consists of seven layers that are linked in service in order to communicate the organizing logic of the communication stack from the application to the physical medium that communicates the bits.  Similarly, EA is ordered into business, information, application, and technology infrastructure in order to provide the organizing logic of the enterprise or part of the enterprise represented in its business architecture as a system component.  It is from here that many industry experts have drawn the connection that the enterprise can be ordered in layers, just as a systems architecture is ordered to provide transparency into the lineage and traceability between the layers to the physical infrastructure run-time.

Diagram: Retrieved from http://nsgn.net/osi_reference_model/images/diagram4.jpg

References:  https://msdn.microsoft.com/en-us/library/ee658117.aspx#LayeredStyle