Architecture Made Easy, Part 10

First I should mention that there is enough material that pertains to this subject that it can easily be turned into one or more books that illustrate the various architectural patterns for software engineering. For anyone with formal training in software engineering, you will yearn for much more detail than can be covered in one article, but at a minimum you will hopefully find that this article does an ample job of summarizing the overall framework of software architecture for information systems, although omitting control systems and hybrids.

Architectures play an important role with respect to every aspect of software system development. Furthermore, the overall maturity of any individual architecture can be assessed using methods similar to the Carnegie Mellon Software Engineering Institute maturity levels for process maturity. However, before discussing the impact of maturity level of any given architecture, which we will save for later articles, the value of minimally developing the first level architecture for each discipline cannot be overstated.

Think of it like the process of producing an award winning wine. The number of disciplines and factors that contribute to a fine wine are great and complex, and although occasionally a great one is produced, it only happens with regularity if several disciplines have been well mastered, the tools and technology advanced, the process well managed, and the initial conditions appropriate. For both wine and software, it is the “system architecture” that encompasses the primary subordinate architectures; and although these architectures may be developed in parallel or in any sequence, they may be developed into their natural sequence.

Most architectures among “information systems” have a well-defined engineering scope; however, there remain a few that are too unspecific to be particularly meaningful and as a result are subject to varying interpretation, such as technical and solution architectures. For this reason, these will be omitted.

The architectures that have a specific, or specific enough, engineering scope include:

System ArchitectureThe system architecture ties the major components of the business architecture, application architecture and data architecture together into a unified diagram.

Usually organized within an enterprise architecture department, the primary artifact of the business architecture is a business framework for organizing the many business steps into unambiguous and easy to manage collections of business capabilities, referred to as the business capability model, usually spanning all areas of the business, but it also includes business events, operational flows, steps within those operational flows, manpower, organizational structure of manpower, signature cycles, and the various informational inputs and outputs that support the flow of business data.

It should be noted that if we automate portions of the business architecture, it does not remove it from the business architecture. Instead, the business architecture is blended with the business applications and hardware that augmented and or displaced manpower and the organizational structures that previously supported those tasks manually. Automation may improve accuracy, and consistency.

Information Architecture2

As the saying goes, “You cannot make a silk purse out of a sow’s ear,” and hence, if the information is poorly understood, or of poor quality, nothing good can come of it, no matter how mature your architectural practice may be. As such, information is like the grapes that result from the harvest… if either they are of poor quality or their characteristics are unknown, little else is going to matter.3

Information is everything, and cannot be compensated for when it is neither understood nor meaningful. There are various informational inputs and outputs associated within each step of an operational business flow, which are found on forms where information originates and on reports where it is consumed by the business.

Whether automated or manual, all information is collected, analyzed, and then developed into a framework that organizes it into unambiguous and manageable collections of information that those fluent in the business can readily relate to, referred to as either the logical information architecture or logical data architecture (level zero).4

Enterprise architecture requires a broad knowledge of business and technology to ensure that the priorities of the business and stakeholders across the enterprise are addressed by a cost-effective combination of business operations and technology.

Enterprise architecture is a natural result of the growth of IT inefficiencies and the disconnect that tends to result as IT grows. The primary role of enterprise architecture is to place renewed emphasis on the challenges faced by the business, which usually consists of costs that spiral upward with a commensurate decrease in responsiveness to business needs.

Prominent responsibilities of enterprise architecture usually include application and technology portfolio management, business architecture, information architecture, application architecture, and architecture governance. Enterprise architecture is concerned with mapping business capabilities, applications, technologies and data to one another to improve its ability to compete in the marketplace by eliminating waste and better adapting to change.

The artifacts of enterprise architecture include governing principles and a variety of current and future state architectures including frameworks, guidelines, standards, blueprints, and reference architectures that provide architectural guidance across the enterprise.

Network ArchitectureNetworks are comprised of backbones, routers, switches, wireless access points, access methods, communication protocols, network server operating systems, monitoring tools and software.

The network architecture encompasses the functional organization, configuration and operational principles and procedures that are used to manage the various components that comprise the computer network sometimes in the context of one, but usually multiple systems.6

Hardware ArchitectureThe hardware of an information system pertains to physical components, such as data center power supplies; environment control systems; computing platforms, including application servers, database servers, network servers, failover servers, disaster recovery servers; load balancing equipment; networks; their types (e.g., Intranet, Extranet, Internet); topologies (e.g., grid, mesh, star, bus); media types (e.g., fiberoptic, infrared, radio, twisted wire); size (e.g., SAN, LAN, WAN); protocols (e.g., xDSL, TCP/IP, T1, T3); line types (e.g., dedicated, non-dedicated); traffic types (e.g., data, voice, image, video); shared peripherals; and equipment supporting the I/O substructure, including RAID, and database mirroring.

Platform Architecture

The platform consists of the computing platform instances and the major hardware and software components that comprise the computing platform including its I/O substructure.

Platform architecture encompasses the organization, configuration and operational principles and procedures that are used to manage the on-board hardware and software components of the computing platform(s), their interfaces, and major peripherals.7

Infrastructure ArchitectureThe infrastructure of IT consists of the combination of servers, networks, middleware and software that support the application development process, production applications, and other IT services, such as email, content management, and issue management.

Infrastructure architecture encompasses the functional organization, configuration, and operational principles and procedures that are used to manage the inter-related components across the enterprise that comprise the computing infrastructure in the context spanning multiple systems.8

Security Architecture

Although enterprise information security architecture (EISA) is heavily focused on information security, it is a business and regulatory aligned framework to secure data and processes from the perspective of hardware, software, and physical security in a manner that is effective, maintainable, cost effective, and adaptive, encompassing both business operations and their automation support, including IT governance and management.

Software Architecture

There is no shortage of definitions for software architecture in the industry, which range from the way that an application program is structured, to the big picture of the major software types and brands of software across the complete system, and the relationship that these types and brands have to one another.

Those formally trained in software engineering tend to adopt the ‘big picture’ perspective within the context of a system. This definition of software architecture identifies the major types and brands of software, such as the operating systems, database management systems, programming languages, and array of COTS software products.

Each category of technology can then be diagrammed to depict the primary capability of the product by other dimensions, such as type of hardware, operating system, or DBMS, which readily illustrate technology overlaps and gaps.

Data Architecture

From a high-level perspective there are three areas of concerns that are pertinent to data architecture, which include the management of data related disciplines, technologies, and the management of data itself through data architecture.

Disciplines include activities such as: standards, governance, metadata management, data integration, modeling, life cycle management, reporting, analytics, data stewardship, compliance, disaster recovery, master data management, and data security.

Technologies include capabilities, such as: data administration, monitoring, archival, backup, recovery, CASE, change control, data communications, data privacy, data quality, connectivity, development, reporting, and business intelligence.

Data architecture includes a logical data architecture, which provides a business map of data across the enterprise, as well as a current and future physical data architecture, which illustrates the physical location and usage of data across the data landscape.

Database Architecture

At a basic level, database architecture is sometimes considered to be the low-level physical design decisions, such as vertical partitioning or horizontal partitioning, which is also referred to as database sharding.

From a big-picture perspective, however, database architectures refer to the overall design architecture of the database as a database product, such as the following:

• Hierarchical database – is where data records are organized in a tree-like structure with pointers that connect parent records to child records, where each child can have only one parent.9
• Network database – is where data records are organized in a network-like structure with pointers that connect parent records to children records, where each child can have any number of parents.
• Inverted list database – is where records are stored in the data layer and keys (a.k.a., descriptors), are stored in a key layer, (a.k.a., associator). The associator maintains a list of the descriptor fields, such as “eye color” with a list of pointers for each data value (e.g., blue, green, hazel, brown, and black) of each descriptor. The DBMS then evaluates the intersection and non-intersection among sets of descriptor pointers to determine which records to retrieve from the data layer.
• Object database – is most similar to a relational database with a similar query language that employs pointers.
• Relational database – is a database whose records are independent of pointers, with the exception of indices, usually b-tree indices, which provide a more direct path to the rows of data.
• Columnar database – is a database that stores data organized by column, which is advantageous for data warehouse and analytical applications, rather than rows or records, which are advantageous for transactional applications.
• Graphical database – or geographic information system, is a database that links data to locations on a map, thereby linking cartography and database technology.
• Cloud computing database – is a database ideal for unstructured and semi-structured data, where the least structured data is housed at the lowest layer, and then increasingly structured layers of data are built above. Some cloud computing database architectures limit themselves to specialized file organizations and access methods (e.g., GFS, HDFS), while others embed a relational database within the cloud, while others employ a hybrid.
• Massively parallel processing database (MPP) – is a database design, usually based in the relational paradigm and accessed using either SQL or SQL-MR (i.e., SQL map reduce), which moves the logic for analysis and business intelligence over the application server database server boundary to the database server to achieve efficiencies by avoiding iterations of communications and data movement. An MPP may be implemented in a parallel processing environment (e.g., Teradata) or on many single processor machines linked together in a cloud computing type of environment.
• Complex Event Processing Database (CEP) – is a database that renders patterns of data for queries against streams of data for real-time filtering or aggregation during data transmission for either non-persistent data or persistent data before it approaches a permanent storage device.

Application Architecture

Depending upon the classification of automated system10 (e.g., control system, information system, hybrid system) a variety of application types exist. Focusing solely on information systems, the major types of applications consist of the following:

• Portal – is generally a sandbox of interactive web-based objects accessed through a web browser that are available to an end-user to do perform navigation to another portal or to a web application, view or manage information or documents, support aspects of collaboration, or interact with widgets that may provide a variety of calculation or illustration capabilities.
• Web application – is a program or series of interactive programs that provide a business, educational or entertainment capability within a web browser to an end-user, such as on-line retail or banking.
• On-line transaction processing (OLTP) application – is program or series of interactive programs that provide a business, educational or entertainment capability to an end-user within a “mini-operating system” like environment, such as IBM CICS, IBM IMS-DC, or CA IDMS Central Version environments. OLTP environments provide a variety of capabilities, such as automated recovery restart, security, resource management, and operating system interface services.
• On-line batch – in some situations on-line transaction processing applications are designed to not interact with users, which would classify them as an on-line batch application, which instead of receiving its system services from the operating system, it receives its system services from the OLTP mini-operating system, which in turn receives its system services directly from the operating system.
• Batch – is a program or series of programs that receive their system services directly from the operating system, and which usually process a collection of transactions consecutively one after the other, with no additional interaction with an end user after the program starts; in rare circumstances there may be limited interaction with a computer operator who supervises the production environment.
• Interactive batch – is a program or series of programs that receive their system services directly from the operating system, and which interact with an end-user.
• Workflow automation application – is a program or series of programming components, sometimes modeled using a business process modeling tool, that guide end-users through the sequence of operational steps that define the operational process that they participate in to perform their work, including the receipt of requests for service, queuing and routing tasks to individuals fulfilling the required roles, including signature cycles for needed approvals, while automating the non-intrusive collection of metrics for management reporting and analysis.
• Simulation – is software that ranges from a simple mathematical model to a massive system that imitates the characteristics of a physical or abstract system with the objective of safety engineering, testing, training, research or rendering a virtual reality experience involving any combination of the human senses.
• Game – is software that operates in both single and multi-player mode, gathering player inputs and rendering player feedback from an embedded simulation software application.
• Autonomic computing – is defined as software that manages its applications and tasks without end-user input pattered on the autonomic nervous system regulating various bodily systems of an animal to support various capabilities, while hiding the overall complexity of the system from the end-user. This is actually quite similar to how operating systems themselves work, which are themselves a major application type.

Application Architecture Design Patterns

Although each major application type may have one or more architectural patterns, each architectural pattern may draw from a number of design patterns. Among the most common and or useful design patterns to be aware of are:

• Integration pattern – identifies whether the architecture sub-type is a silo, fully integrated, or sharing common sub-systems (a.k.a., subsystem interface pattern).
• Distribution pattern – identifies whether the architecture sub-type is non-distributed, distributed, peer-to-peer (P2P) distributed (e.g., pure, hybrid, or centralized peer to peer), grid, or cloud.
• Tier pattern – identifies whether the architecture sub-type is single-tier, two-tier, or n-tier, which is usually a three-tier pattern consisting of presentation, application and data.
• Procedural pattern – identifies whether the architecture sub-type is unstructured, structured, object-oriented (OO), service oriented architecture (SOA), rule-based (expert system), statistical model, or non-statistical model (neural network). Object oriented procedural patterns employ what is called the “Law of Demeter” or “Principle of Least Knowledge,” which is a layered architecture that does not permit a program to reach further than an adjacent layer of the architecture, and hence it is said that each program can only talk to its friends.
• Processing pattern – identifies whether the architecture sub-type is single-threaded, tightly coupled parallel processing, or loosely coupled parallel processing.
• Usage pattern – identifies whether the architecture sub-type is consumer to consumer (C2C), consumer to business (C2B), business to business (B2B), business to employee (B2E), business to government (B2G), government to citizen (G2C), government to business (G2B), government to government (G2G), or local usage.
• Analytical pattern – identifies whether the architecture sub-type is statistical, neural network, or simply multi-dimensional, however, neural networks as an example have at least two dozen design patterns associated with them, each tending to be useful for different types of problems and types of data.
• Interactive pattern – identifies whether the architecture sub-type is conversational, which waits for a response, or pseudo-conversational, which does not wait, but instead starts a new instance of a task to handle the response if and when it arrives.
• Process communication pattern – identifies whether the architecture sub-type is synchronous or asynchronous. For example, a type of synchronous communication pattern is the reactor design pattern which simply receives inputs from multiple sources, and then dispatches their execution to the appropriate routines synchronously.
• Data communication pattern – identifies whether the architecture sub-type transmits data using a push approach, such as an enterprise service bus (ESB) that transmits data as it occurs; a pull approach, such as with extract, transform, and load (ETL) that transmits data in a batch on demand or on a schedule; or a hybrid approach that uses ETL within an ESB.
• Message dissemination pattern – identifies whether the architecture sub-type sends information directly to a predetermined recipient or subscribing recipients, or indirectly through publishing or broadcasting.
• Resource sequence pattern – identifies whether the architecture sub-type processing sequence intentionally orders the locking of shared resources as a means to proactively prevent the possibility of a deadly embrace across logical units of work.
• Pipeline patterns (a.k.a. pipe and filter)11 – identifies whether the architectural sub-type, whether multi-processor pipeline or single processor ‘pseudo’ pipeline, are patterns architected as a series of queues that enter their respective routines. The queues that messages travel on are referred to as pipes, and the processes that reside at the end of each pipe are referred to as filters. Each filter processes messages sequentially in a first in first out fashion (FIFO), although parallelism can be achieved by instantiating more than one filter for a given inbound pipe. These patterns are typical in operating systems, such as MVS, UNIX, VM/CMS, and Windows, as well as ‘mini-operating systems’ such as OLTP environments, such as CICS and IDMS/Central Version, but is a pattern that is used among other types of applications.

• Event driven patterns – identifies whether the architectural sub-type triggers processes implicitly or explicitly when events come into existence. Explicit invocations occur when a process invokes a subsequent process directly, whereas implicit invocations occur when a process stores data in a shared location or transmits a message for other processes to detect on their own.
• MV patterns – are a family of architectural patterns consisting of: MVC (model-view-controller), MVP (model-view-presenter), MVVM (model-view-viewmodel), HMVC (hierarchical-model-view-controller), and PAC (presentation-abstraction-control) that organize responsibility for different user interface elements within an application, such as in a shopping cart application, to facilitate independent development, testing, and maintenance of each component.
• Blackboard patterns – are patterns where a deterministic strategy is not known to approach a problem requiring a diverse set of processes to render partial solutions to a problem to a shared buffer, which is then monitored by one or more other processes that attempt to recognize a solution to the overall problem from the information continually evolving within the buffer.

Procedural Pattern Combinations

To develop a fine wine after the harvest, one may blend acidic grapes picked first in one part of the vineyard with sweeter and more developed grapes of the same or a different variety picked later from another part. Likewise, one may blend different architectural patterns, such as SOA and OO to achieve an application with the best overall combination of characteristics.

The notion of SOA is to develop “business” functions that will be reusable to subsequent application development efforts. The way to identify what collection of functionality is appropriate to encapsulate is to perform a classical functional decomposition only down to the point just before which the units would no longer be recognizable to business users, which are referred to as business services.

The best way to understand OO is to review its origins in control systems, where each object is literally a physical component that you could touch, such as an anemometer or throttle, and software pertaining to that physical component would be organized into packages corresponding to those components. This form of compartmentalization leads to a high degree of reuse, and hence compact applications for control systems that are easy to maintain.

When OO made the leap to information systems, the initial challenge was in identifying the “objects” about which to associate and organize software. For an OO approach to be successful, the objects themselves must be stable, and as you might guess, the only artifact that could be a candidate to meet that criterion within an information system is the data, or more specifically, the logical data architecture level zero.

Conclusion

Whether it is architectures in electronics that facilitate affordable high-definition 3-D flat screen televisions that are now entering the marketplace, architectures in game software that facilitate advanced interactive computerized games that tantalize both children and adults, or architectures in wineries that facilitate more quaffable wines in shorter and shorter timeframes, it is the presence and continual development of architectures that make it possible to achieve greater results with increasing ease and efficiency.

When it comes to architectural frameworks, methodologies, or standards, perhaps the most important framework to mention is The Open Group Architectural Framework (TOGAF), which provides neither specific architectures of its own, nor maturity levels, nor architectural guidelines. Instead, TOGAF is a framework intended to assist in the development of specific architectures, maturity levels and guidelines.

In contrast, Gartner/Meta represents a rather loose architectural practice; The Zachman Framework is a taxonomy for organizing architectural content into a matrix of what, where, when, why, who and how; FEA is an Enterprise Architecture; DoDAF is an architectural framework designed to bring specific architectures together; and Carnegie Mellon University’s SACAM (Software Architecture Comparison Analysis Method) is an approach for evaluating the strengths and weaknesses of existing architectures.

Architectural standards are often developed by a myriad of standards bodies, of which one of the more prominent is the International Organization for Standardization (ISO) involving international standards for business, government and society. As such, there are ISO standards for various computer hardware and software architectures, as well as a standardized series of wine glassware for professional wine tasting13, which are stemmed with elongated tapered bowls, with capacities of 120 (for sherry), 210 (for white), and 300 or 410 millilitres (for red), best with a Grand Cru red Burgundy, which is guaranteed to have an abundance of structure and architecture all of its own.

Please feel free to let me know if you enjoyed this article, and don’t hesitate to indicate which articles in the “Architecture Made Easy” series are useful to your organization. In addition, corrections, enhancements, and suggestions are always welcome and are requested. Please note that regarding this topic, there is much more to come.

[Architecture Made Easy: Architecture Patterns is the 10th article in the AME Series created by James V. Luisi.]

End Notes:

1. In-depth business knowledge was commonplace prior to automation. However once large areas of business operations became automated with the overwhelming majority of business rules embedded into computer code, the detail knowledge of business operations that was once commonplace is nearing rapid extinction.

• For those who are familiar with MIL STDs, the data subject areas found in the US Army AR-25-9 was among the first useful representation of information architecture of large scope, encompassing both a level zero and level one of the logical and physical information architectures.
• Likewise, great wine can never result from grapes of poor quality. The variety of grape must have the potential of producing fruit with great character and the variety of grape must be well-understood to be handled correctly.
• Information architecture should not be confused with ‘data architecture’, which deals with data architecture disciplines, technologies, and only data within the envelope of automation.
• From the perspective of viticulture, this function would determine what products are most advantageous in the marketplace that the wine producer wishes to cater to, and in response a set of plans would have to be developed to determine which vine stock to plant, which must be uprooted and or relocated, which processes to perform manually or automated, and what equipment and technologies will be required, and how to phase them in.
• Within and across a winery, temperature readings of vineyards and fermentation vats, as well as a variety of chemical measures from the various stages are networked back to initiate manual and or automated responses.
• The platform architecture of a winery may include the components of fermentation equipment, its temperature regulation, content mixing, wine pumping and equipment cleaning components.
• The infrastructure of a winery consists of the hardware, software and manpower necessary to prune, test, harvest, transport, press, ferment, rack, age, blend, fine, bottle, package, warehouse, and ship the wine.
• Data models that restrict themselves to hierarchical representations are sometimes referred to as canonical data models. The notion of a canonical data model is a model that employs a common format, which is independent of any specific application, often thought to be analogous to XML.When using a canonical data model the process of transferring data from application / database “A” to application / database “B” requires a transform between the originating application “A” to render the data into its canonical form, and then a second transform between the canonical form to application “B.”

• The three main types of systems are information, control and hybrid systems. Control systems live in the tangible world of physical objects, operating mechanical equipment like flying a B-2 bomber, which is far too complicated for a human-being to fly without a computer, and information systems, which focus on the manipulation of data in the world of both tangible and intangible ideas and concepts. Hybrid systems are a combination of control and information systems, such as a control system embedded within an information system, or an information system embed within a control system.
• This is an architectural style that divides a larger processing task into a sequence of smaller, independent processing steps, referred to as “filters,” which are connected by channels, referred to as “pipes”. Each filter exposes a very simple interface receiving inbound messages from an inbound pipe, then processes the data, and then generates a message on an outbound pipe. The pipe connects one filter to the next, until the processing is complete.There are a number of architectural sub-patterns based on pipeline patterns, such as the aggregator sub-pattern, which is a special filter that receives a stream of messages and correlates the ones that are related, aggregates information from them, and generates an outbound message with the aggregated information. In contrast, a splitter sub-pattern is a special filter that separates messages into subsets that can be routed to distinct outbound pipes.
• For a more complete list of messaging patterns and sub-patterns of architectural sub-types, refer to Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions by Gregor Hohpe and Bobby Woolf, 2004, published by Addison-Wesley, ISBN: 0-321-20068-3.
• Glassware for professional wine tasters employs a clear, colorless glass that will not interfere with viewing the color of the wine, a base to support the glass, a stem for handling the glass without warming the wine with the hand, the bowl to hold the wine, and a tapered rim to concentrate the aroma of the wine at the top of the glass.There are a variety of characteristics that one may discern of a wine visually, such as its approximate age, alcohol content, style of wine, and sometimes origin. Upon viewing the body of the wine, the colors purple, ruby red, red, brick red, and brown indicate the progression of age.An additional visual clue of age would be the contrast of color between the body of the wine and the wine located at the outer rim of the wine against the glass. If the wine at the rim is as rich in color then the wine is young, usually one or two years, whereas increasing gradients of translucency indicate.