SOA, Redefined

Once upon a time, SOA (short for Services Oriented Architecture) was the king of IT Hype; for years people talked incessantly about it, attempted to extol its virtues and many tried using it within their own enterprise environments. SOA has had mixed success over the years, but that's somewhat hard to measure for a number of reasons, including:

1. There were conflicting definitions for it to begin with - some viewed it more as a practice or design approach, others viewed from a product perspective and still others saw it as a standards focused phenomenon. 
2. What SOA was has morphed quite a bit from where it began - it has changed so much in fact that it can hardly even be referred to in its own context any longer. We'll explain that in a minute. 
3. It was never entirely clear from the initial hype, what the real benefits of SOA would be if adopted. That has changed somewhat since the mid-to-late 2000's but that's only because the solution context evolved.

SOA drives design on the right side of this picture...

So, let's back up for a moment and first look at what SOA at several different points over the past decade. 

In the misty depths of the turn of the new millennium...

• In 2004, innovations in software engineering - notably the notion of Object Oriented programming techniques and languages along with pattern-driven design had begun to change the perception that applications must handle redundant tasks each time they faced them. In other words, the notion of software that could be shared as services through abstracted interfaces was becoming popular. The core design concept was extrapolated outwards to an enterprise scale and the first serious discussions about SOA as a practice or set of architectural principles began in earnest. 
• On a parallel track, the W3C (World Wide Web Consortium) Microsoft and several other companies began plotting out a standard communications protocol for linking software objects or services across the Internet. The standard, later called SOAP (Simple Object Access Protocol) was part of a larger set of W3C standards including XML, XHTML, CSS, DOM, WSDL and UDDI which when taken together would provide standard approaches toward encoding data, passing it and locating the places it was hiding as well as defining the format for how to display it. SOAP was adopted in 2003. 
• Also around this time a set of data management technologies emerged; partially based on EAI (Enterprise Application Integration) and ETL (Extract Transform & Load), that linked SOAP with Services concepts in the context of data movement. This new technology was called the Enterprise Service Bus (ESB).

fast forward to 2006-2008...

• A vast array of products have been restructured to accommodate the design principles which have matured somewhat. These products were formerly application server platforms and other governance management tools among others. The "SOA Stack" had been born.
• Industry hype probably reached its apex around this point. SOA projects were popping up everywhere and the idea of what SOA meant was little clearer.
• That definition focused on key design principles (such as "loose coupling" and "encapsulation" both borrowed from Object Oriented Design) and core elements of the stack (which had just evolved) - so the typical SOA solution would follow the principles and use the stack (starting with an ESB, then applying a UDDI registry, governance tool, business process manager and the appropriate app server / container, such as weblogic or websphere etc.)
• Java figured prominently in the SOA landscape, which only makes sense given that SOA evolved partially from Object Oriented Design techniques and principles. Thus, a great many of the SOA projects chose J2EE as the development language because it was designed to support OOD. 
• Some larger organizations, like the DoD, wanted to take this all further and bundle identity management and infrastructure services along with SOA initiatives. This was the beginning of a transition from consolidated hosting environments to Cloud Services in the Federal ecosystem. 
• On the commercial side, something called Software as a Service began to emerge at this time (it had in fact been around before then but got rebranded as SaaS). It involved the notion of a subscription to get thin client applications served directly from the service provider.  
• Virtualization becomes an interesting way to not waste CPU cycles in the datacenter.

2010

• Dave makes contact and the next generation of HAL computers malfunctions yet again! - sorry couldn't help throwing in the obscure sci-fi reference...
• Smart phones conquer the world. This part is accurate - it did happen and it came as a bit of surprise. It also changed the way we looked at development platforms, delivery platforms and 'object communication.' RESTful services, which had been around for awhile, got a huge boost in large part to the explosion of 'apps' being developed and deployed to IOS and Android devices. SOA would never be the same...
• Let's not forget DropBox, Google Drive and a 100 other Cloud offerings that began appearing around this time. Infrastructure got sexy.
• Oh, and everything turned "Agile."

2012 - 2014

• The longest war in American history still isn't over yet. When it started, enterprise IT was still largely mainframe driven - ten years later - what diversity we find...
• The popularity of Object Oriented Programming has hit the skids so to speak. This is because the scripting languages have overtaken J2EE in popularity as those languages support Agile and mobile platforms better (J2EE is still around of course, but then so is Cobol - the coding is on the wall). 
• People seldom refer to SOA projects anymore - or SOA has become synonymous with application architecture where organizations have more or less adopted the principles. Often times now its being done with REST instead of SOAP.

So, now that our tour of the past decade has brought us full circle back to the present; how would we go about defining SOA in 2014? Wikipedia defines it almost as a single pattern - others - like Thomas Erl - have written very interesting books on it.

Services Oriented Architecture (SOA), Redefined

SOA represents a nexus of design principles and standards for internet-driven applications. There is an implied reliance on specific toolsets that support the resulting services created based upon those principles and standards, but those tools do not define SOA any more than Object Oriented Design is defined by Eclipse. In other words, you could conceivably use any number of other tools to produce a solution that might conform to those principles or standards.  

The notion of enterprise services, Managed Services and Software as a Service (thus much of Cloud Computing) are natural extensions of the core SOA concept, but aren't SOA (anymore than SOA is OOD even though it is largely derived from it). SOA or for that matter OOD can be used to help facilitate parts of these other solutions. 

In the context of our blog here, I like to think of SOA and OOD has subcategories within the practice of Application Architecture (which itself fits within Solution Architecture). Management of enterprise services which may have been created using SOA fits into Infrastructure Architecture. Obviously, when one works on an application service that is intended to have a Cloud or SaaS element to it (or must rely on enterprise services to function), multiple architecture tiers or practice areas will be involved - which is another good reason to have IT Architects who can handle it all, right?

opyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Application Architecture, Defined

As part of our initiation of the IT Architecture Journal, we've been trying to help define the landscape - we're continuing that trend today with an introduction to Application Architecture. These definitions are being provided as a foundation - both for IT Architecture education in general but also as part of our larger goal to help harmonize industry terminology and expectations regarding IT Architecture. And of course these articles also serve as a foundation for us as we delve into more detailed or specific topics later. Like so many other aspects of Architecture - there is quite a lot of overlap and complexity connected to Application Architecture.

The definitions we provide here are not meant to be mere academic representations of some well understood a priori knowledge, but rather are based on experience from many years of architecture practice. The goal here is to provide the most pragmatic explanations possible - and to clearly link what might otherwise appear to be conflicting concepts. In other words, we are attempting to demystify IT Architecture.

First, let us address the overlapping or conflicting terms. Application Architecture is often referred to as System Architecture, Systems Engineering or even Software Architecture or Design (or even Software Engineering). All of these terms are roughly analogous and can fit neatly within the scope of Solution Architecture (which is itself a subset of IT Architecture), yet there are aspects of Application Architecture practice which are stretching the bounds of what it encompasses. Even within some of these other terms there lies deeper hierarchies of sub-terms; for example within Software Engineering we'd likely find both Object Oriented Design and GoF (Gang of Four) Pattern Design. When we begin to discuss SOA (Services Oriented Architecture) and SAAS (Software as a Service) then things will get even more complicated as we will see.

Application Architecture would be focused mostly within the Business Tier of this view

Application Architecture, Defined
Application Architecture is the set of design activities and artifacts associated with the production or management of solution logic. Solution logic is the set of business rules and functions that support key processes or workflows associated with any given organization. While Application Architecture requires and / or manipulates data and sits atop an infrastructure it often viewed separately from those elements in organizations where infrastructure as a service or data management organizations are in place. There are usually clear delineations regarding where application responsibility ends and data or infrastructure etc. begin.

Application Architecture generally follows systems and software design guidelines or expectations; so an Application Architect would likely use UML to create Class diagrams to help model data for their application, whereas a Data Architecture would likely use an ERD or Dimensional to do something similar (even though both are working with the same data in that context).

Application Architecture is represented in most of the major EA Frameworks; in TOGAF and FEAF it is referred to as Application Architecture, in Zachman it Systems. In DODAF it is roughly equivalent to Systems and Services Views.

Skills Required
To work as an Application Architect, you'll need the following skills:

• The ability to design and problem solve.
• The ability to use UML notation to capture standard designs.
• The ability to apply standard patterns or create / define your own.
• An understanding of the underlying technologies involved. Object Oriented design in Java is generally quite a bit different than scripting with JavaScript and Perl in a LAMP stack. 
• The ability to understand and harness / exploit an Application Development Lifecycle and associated tools - this is referred to in industry as Application Lifecycle Management (ALM). 
• The ability to translate business needs into business logic and to define integration of that logic within the system environments available. 

A Note about SOA
So, what makes SOA a game-changer for Application Architecture? Basically it has to do with implied integration across other "tiers" of the overall Solution Architecture. SOA brings with it a sort of mega-pattern for design that includes expectations for data access and infrastructure exploitation and thus it is sometimes hard to abstract these non-application elements of the solution. While it's easy enough to abstract all this from the developers (you simply give them the guidance and the self-service development environments) for the architect it's not so simple. We'll be talking about this more soon...

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More