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