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.

A couple of months back I was taking a class on sketching at the Art Institute Museum. I was trying to learn how the UPS guy on the commercials can draw on a whiteboard and talk at the same time.  Needless to say this was not on the topic list.  Instead there was the topic of negative space.

What is negative space you might ask?

We will get back to that in a second...

Anyhow we got our stools to sit on, were handed charcoal and some paper, and sat at the top of the steps in the front lobby of the museum.  On the walls were these grillwork patterns that one will see on a building.  Complicated criss-crossing lines that made sense when viewed 20 feet away, but look too complex to even contemplate when viewed 1-2 feet away. The instructors asked us to draw them. There was the collective gasp as we realized that none of us, even the ones that had previous art training, had any chance of drawing them.

Then came this idea of negative space. The instructors asked us to draw the spaces between the grillwork. They wanted us to forget about the grillwork completely and draw what was behind it. Sounds strange, doesn't it? As I did this on the first grill I started drawing shapes.  When I looked at these shapes up close they all looked unrelated. As I drew more and more my sheet started to look like a bunch of weird shapes all strewn out on the paper.  This certainly appeared to be some strange exercise in futility. The instructors asked us to pull the paper a few feet away and "Voila," all of the shapes disappeared and what remained was the grillwork. It appeared the minute that I looked at the paper as a whole.

So what does this have to do with enterprise architecture?

Technology is a big part of enterprise architecture. Our tendency is to see everything within the confines of a technical implementation. "Which technologies make sense?" "Which ones do not?" "Is this a place for cloud computing?" "How does this fit in with SOA?"  If an we have a technology stack in place the questions are immediate. How does anything we want to do fit in with what is already there? 

Another way to ask these questions is to forget about the technology and infrastructure entirely. Start asking what would the situation be like if there was no technology at all. What would this mean to do this without technology? Do the design at the same level of abstraction as you would with the technology. Even forget that the users have computer screens, mobile phones and other devices.

This is negative space thinking. 

Ever wonder how files, trashcans, folders, and many or the other monikers ended up on personal computers?  These were not just pictures that were familiar to the user, they operate in the same way as their real-life counterparts.  We empty a trashcan,  we organize our files into filesystems, which were originally file cabinets.  How did this help in design?  It wasn't too hard to imagine putting all of the files that we have in file cabinets into the computer.  There was this instant connection. 

So how does this happen? How is this accomplished?

The iterative model gives us a great start.  Focus on these smaller stories instead of the big picture. As these stories are defined use common artifices, like the trashcans and folders used before, that are proxies to technology. Instead of databases think of lists, schedules, and papers. As these are brought together into the bigger story these pieces should start to converge. Looked at closely, these are just pieces of data, looked from afar and technology will start to emerge. 

What if you have the overall story already?

That is OK and a good thing.  This provides the scope and context for our stories. The trick is to avoid decomposing the larger stories into the smaller ones. One might see the overall grill and should. Instead of splitting the grill up into sections start finding and drawing the white spaces. Eventually, the internal grillwork will emerge. The same thing will happen in our case as well!

How are enterprise architects going to enable the business agility that is so critical to enterprises today, as they seek to stare down growing global competition, and harness opportunities to prevail in new markets? The way forward is to tighten up adherence to five critical principles that always have guided — or at least, should have guided — enterprise architecture (EA) efforts. Slackening the reins may seem to be the way to get moving faster, but trust me — that’s only a temporary speed burst. It won’t set you up for the long haul.

So, let’s look with a fresh eye at some of the key steps to help you soundly respond to growing pressures.

Improve the Business Case

Often the best, and quickest, way to meet business needs is to more clearly define those needs in the first place. Spending a little more time up front to better define and communicate the business requirements behind the architecture will result in a more concise solution, and even greater time savings at each step along the way.

Here, the principles to follow are not unlike those your CIO must adopt to build a business case for any tech investment. A good primer to read is featured here in Smart Enterprise Exchange. Joe Peppard, Professor of Information Systems at the Cranfield University School of Management, explains the importance of improving the process used to build a business case — and doing so makes as much sense for the enterprise architect as it does for the CIO. After all, if the business case is weak or lacking, the architecture may be incomplete.

An effective process is one that involves a number of factors. For example, a complete cost/benefit analysis outlines all of the benefits to each business goal or need, remembering that these often can be more than monetary returns.

Another “must” is thoroughly examining the costs and risks associated with each business goal. Also, remember to involve parties ranging from business analysts to key development managers, as their feedback can result in a more refined business-needs analysis. At the same time, make sure to leave room for contrarian views that can be a spur to innovation and better ROI.

Improve Communication

IT architecture has little value if it cannot be thoroughly and clearly communicated to business and IT partners.

So you’ll need to:

• Document the architecture clearly using standard methodologies and guidelines for the areas you’re architecting. Use Unified Modeling Language (UML), the Open Group’s service-oriented architecture (SOA) ontology, or other methods such as Martin Fowler’s patterns for enterprise architecture (EA) (see Patterns of Enterprise Application Architecture, Addison-Wesley, 2002). It’s fine to combine methodologies, but you should strive for consistency.
• Allow for two-way communication. Avoid dictating to others what needs to be done, and how. Instead, create a culture and process that’s open to all opinions.
• Create working groups for key areas, involving all stakeholders in these groups, led by experts.
• Iterate the architecture through open discussion with the business on one side, and development on the other.  

Following these guidelines will result in a living, evolving architecture strategy that moves quickly to meet the ever-changing business and technology landscapes.

Ensure End-to-End Accountability

An enterprise architect and his/her vision can quickly become irrelevant if he or she is not involved in the end product. Accountability is key for success at all levels and has the following benefits:

• It ensures that the architectural vision is carried through from definition to implementation.
• It ensures buy-in along the participant chain, through to development and quality assurance.
• It creates architecture advocates throughout the organization, increasing the number of people who believe in and communicate the overall vision.
• It helps the enterprise architect and CTO put their foot down on silos and “out-of-band” development (otherwise known as skunk works).

Being involved in the development and deployment of the software the architecture defines is the way to ensure that the solution evolves rapidly, and remains relevant to the business. 

Improve Process Measurement

The architecture process should be constantly improved via a feedback loop. Past business technology investments should directly indicate the effectiveness of your architecture vision. To ensure this from the beginning, create key quality parameters to measure and analyze the effectiveness of your architecture each step of the way The Open Group's Architecture Review Checklist, for instance, can be a starting point. It covers questions about general architecture issues, as well as specific items, such as application server technology.

Gauge success of your architecture’s implementation by reviewing :

• Reliability and availability: Did the resulting system have failover and redundancy designed-in?
• Security: Were there any security issues in production that can be traced back to the architecture?
• Modifiability/extensibility/portability: Over time, were development teams able to easily and cheaply extend the system without overhauling or abandoning the original architecture principles?
• Interoperability: Did you design for the integration with future technologies, systems, and data?

If there were deficiencies in your enterprise applications that can be traced back to flaws or holes in the architecture, defining processes to ensure that future architecture work doesn't repeat the same mistakes will help to optimize those areas in the future.

Improve Your Digital Literacy

No one can be expected to know or remember the details of every discipline in a growing world of technology. You should, however, be able to locate, organize and communicate relevant pieces of information quickly and concisely using technology itself as a medium. This involves using hardware (i.e., desktop and mobile devices), as well as software to gather and index the appropriate information. 

Do this correctly, and you can expect to: 

• Stay in front of emerging technology, not just the hot topics of the day.
• Understand what has and hasn’t worked for other companies.
• Remain a thought leader within the organization. 
• Have up-to-date knowledge of costs related to hardware and software deployment as part of an architecture (i.e., basic hardware costs, consulting rates, hosting fees, average ROI for investment in particular areas such as integration, SOA, cloud and so on.)   

I’m going to say it: When it comes to enterprise architecture, be the turtle, not the hare. Take the time to do things right from the start, and the race is yours to win.

I’d love to hear your thoughts about whether such principles have guided and continue to guide your own efforts. Please feel free to share your comments, ideas and experiences with me and your fellow enterprise architects here. See you next week!

Eric Bruno is founder and Principal, Allure Technology Inc., which provides enterprises with online business solutions that leverage Internet technologies and approaches that combine simplicity, rich user interfaces, and service-oriented architectures. Eric also is an expert in full lifecycle, large-scale software architecture, design and development for client/server, highly distributed, multitiered Web, real-time and transactional software development environments. He has worked on large-scale systems, and served as technical advisor, chief architect and development team lead on numerous projects in industries including financial services.