Have you been paying attention to how the mainframe’s role will evolve as your enterprise architecture strategy matures? You should be, considering that these systems continue to make up a significant part of business infrastructure. In several recent independent studies on behalf of CA Technologies, a significant majority of senior-level mainframe decision-makers (between 80 and 88 percent) responded that they believe mainframe applications remain a key business asset. 

My advice is that enterprise architects should be thinking of how to help their companies leverage these data center assets as viable candidates for private cloud-based transaction processing. Modern mainframes fit the bill because they are all about redundant internal components, high-speed and high-bandwidth I/O, flexibility to run both modern and legacy software, high security and extreme reliability. And, as Guillermo Merino notes in Saluting the Mainframe, only Google’s massive server farm comes close to rivaling the mainframe’s transaction-processing scale. 

How to allow mainframe workload processing to continue into the 21st century world of private clouds while reducing cost and complexity? The workflow-centric approach integrates well into modern SOA (service-oriented architecture)-based solutions.

The “Big” Event

An efficient way to integrate classic mainframe processing into a modern private cloud-based SOA is through event processing, where events can be used as inputs and outputs to workloads executed on the mainframe. For example, your Java EE software can trigger the batch processing of perhaps hundreds of thousands of transactions on the mainframe, where the results are delivered in real time, and perhaps stored in a database management system (DBMS) or NoSQL database. Thanks to these triggers, the entire system can remain technology agnostic, with no need to be concerned that it’s a mainframe providing the high transaction-per-second (TPS) processing rate behind the scenes. This is particularly important because it allows enterprise architects to strategize around the mainframe even as COBOL and JCL development skills are on the decline. Many CIOs are concerned about the looming mainframe skills shortage, as older workers with these talents retire and the younger generation isn’t equipping itself to replace them (see this article).

In Figure 1, you can see how triggers throughout the system become events that can be processed anywhere in the data center, including on its resident mainframes. On the left are event sources, processed on the appropriate systems (a DBMS, Java EE servers, mobile devices and so on), with the mainframe on the right as a potential producer and consumer of these messages. As daunting as all this may seem, it’s made quite simple, thanks to the level of abstraction the events supply, combined with packages such as CA Workload Automation ESP software.  

Automating processing in this way makes it possible to plug the TPS power of a mainframe into existing systems without concern for the vast differences in technologies. Additionally, things can run in reverse – that is, SNMP or other events from the mainframe can be processed by other components of the architecture. This dynamic workload processing allows enterprise architects to craft their mainframe strategies to efficiently meet the high Service Level Agreement demands that only mainframes can provide, all from the modern platforms and languages that developers are comfortable with.

Integrating existing mainframe software and capabilities with modern software environments through the dynamic workload processing, software from CA Technologies allows enterprise architects to guide developers in finding the “sweet spot” between the processing options.

For more on how enterprise architects and CIOs are getting the message about how to get even greater value from their mainframe environments, read this piece by Tam Harbert and her update here.. And let us know how you envision the mainframe’s place in your own enterprise architecture strategy.

Recently I’ve been thinking about service-oriented architecture. SOA has been around long enough that it may sound like yesterday’s news. After a decade of formal SOA standards and deployments, organizations have become familiar with what it takes to deploy a SOA, along with its benefits.

Certainly, the financial services industry seems happy with the results. A recent Forrester survey found, for example, that of 80 IT executives from financial services firms around the world, close to three-quarters use SOA and business services in a significant number of business applications in a production environment, and many have plans to extend the SOA footprint in their financial services firm. Nearly 20 percent are planning or deploying SOA-based applications for quality assurance or pilot programs.

But familiarity shouldn't breed too much comfort. There’s always more to learn about any discipline, particularly one such as SOA that is closely entwined with enterprise architecture practices, given how critical such practices are to the business.

One effort that’s worth your getting more education about, for example, is the Open Group's Service-Oriented Architecture Ontology Technical Standard. Here, we’ll take look at how such an effort can make sense in your business, especially if you revise your SOA more than once per year -- making changes or updating the text, for instance.

The SOA Ontology will help you create an enterprisewide set of architecture documents if you don’t have one already, and further refine it if you already do.

SOA Ontology Is a Step to Clarity

As part of the Open Group’s vision of Boundaryless Information Flow, which aims to align IT with the business it serves, the SOA Ontology goals are to:

·         Enable clear communication between business and technical stakeholders

·         Define metadata for architectural artifacts

·         Create a model-driven SOA implementation

In a sense, the ontology is a model of models for developers of SOA-based software systems, expressed in the Web Ontology Language (OWL). It uses natural language to describe concepts and relationships, along with graphic illustrations. Specifically, it uses both XML — with a well-defined schema — and the Unified Modeling Language (UML) to model the system. UML is itself a useful ontology that is used to define whole architectures, models, and even other ontologies.

The Open Group’s SOA Ontology allows you to simultaneously define the interactions between all of the systems and services in your organization (the “big picture”), as well as the design of the individual systems and services. Because they’re often only part of overall enterprise architecture, the ability to clearly communicate the details of your SOA-based systems, their constituent components, their interactions with one another, and their usage within your overall architecture can directly contribute to the success or failure of your enterprise architecture and its implementation. The ontology allows you to clearly delineate the boundaries between SOA and the rest of your organization’s architecture.

The result of having all of the elements, relationships, sequences, policies and so on defined in OWL is a series of artifacts that can be used both visually, to “see” and discuss the SOA, as well as programmatically, to model and implement the SOA design. It’s not a stretch to think that once you accurately describe and visualize your architectural models with the SOA Ontology, you’ll be able to identify weaknesses to improve, missing pieces to fill in, and strengths to use in future projects.

Inside the SOA Ontology

As enterprise architects, you’ll want the technical details about the ontology, so here is a summary of the concepts defined by The Open Group:

The Ontology defines concepts such as system and element (or component), and relationships such as uses and represents (or “is a”), to associate them. Elements in the SOA domain include actors, tasks, services, or other concrete items such as a service bus for communication between services. Relationships describe how the system’s elements interact with one other. A task or service in the ontology associates the actors and elements within the system to describe how the system is used or interfaced with in the overall architecture.

Properties, such as does or doneBy clearly demarcate the responsibilities of the actors in the system. Diving deeper into the ontology, you define contracts, interfaces and information types to clearly state the capabilities of your system’s elements. For workflow-related systems, sequences of tasks can be defined as either a composition (where elements are built from other elements), or orchestration of elements (where elements interact more loosely). In another form of association and interaction, events define and allow for asynchronous communication within the system as well. For security, a policy is used to define rules that govern all of these interactions between elements.

Each element in the system may be a system in itself, which can be used in its more abstract form to describe composite services, or each element can be further broken down and explored using the same ontology.

This creates a system of systems where different stakeholders (business analysts, architects and developers) can dive as deep into the model as required. For example, business analysts can peruse the higher-level system definitions to ensure the entire problem domain has been addressed. Architects can take a more detailed look to determine that business needs have been met in terms of features and Service Level Agreements. Further, developers can dive deeper, examining each service’s constituent components as a road map to implementation. Finally, quality assurance can use it to ensure complete test coverage, end to end.

Visual modeling tools such as Embarcadero's Studio Architect, Troux Architect from Troux Technologies and Visual Modeling Platform from Sparx Systems all help drive architecture from idea to reality. The resulting artifacts take shape as UML diagrams, entity relationship models (ERM), and other object models. Some tools, such as IBM's Rational Rose, can even generate code for multiple programming languages.

If you want to learn more, take a look at the following resources:

·         The Open Group SOA definition

·         The Open Group’s Service-Oriented Architecture Ontology

·         Web Ontology Language (OWL):