Build a stable and agile software foundation in a dynamic IBM i and Microsoft world.

Editor's note: This article provides a summary insight into the white paper The Eight Pillars of An Enterprise Application Architecture. The full white paper can be accessed for free by clicking here.

Imagine your worst nightmare comes true. Your new boss starts today, and 15 minutes into his tenure, he calls you to request, "Please come to my office in 30 minutes and bring the company's official application architecture and guidelines document with you." What would your application architecture document look like? For me, I'd most likely spend my last 30 minutes of employment Googling "application architecture" and pasting excerpts from the search results into a document before security escorts me out the door.

Do we really need a defined application architecture? Yes. Regardless of company size, industry, or number of developers, the answer is still yes. People in disagreement are living in the past, when we only had one programming language, user interface, database, operating system, and server to maintain. Today's heterogeneous environments are a complex mixture of multiple server platforms, interfaces, and development languages.

Luckily, for those of us without such guidelines, Paul Conte has written a white paper titled "The Eight Pillars of an Enterprise Application Architecture: Building a Stable and Agile Software Foundation in a Dynamic IBM i and Microsoft World" that takes the guesswork out of planning a sound application architecture.

The rest of this article consists of excerpts from Paul Conte's white paper, which can be downloaded here.

There's no simple solution to meeting the challenges facing IT organizations today, especially IBM i development groups that are responsible for a large legacy of native applications. Establishing an application architecture involves multiple steps and implementing or acquiring new development resources and tools. But without a coherent approach to modernization and new application development and automation tools to support that approach, there's frankly little chance an IT organization can keep up with expanding enterprise demands and rapidly changing technology.

The combination of greater demands placed on application developers and the increased complexity of the underlying technology has reached a point where the old ad hoc approach to application development is no longer viable. Monolithic RPG or COBOL programs, which were the norm for many AS/400 applications, don't deliver the functionality, integration, or adaptability that's now required.

Although clever IBM i programmers can use system APIs and other techniques to implement Internet communications, browser interfaces, and some of the other elements of modern applications, the required "plumbing code" can be enormously expensive to write and maintain. Most IT organizations simply don't have the technical expertise to create robust versions of this type of application infrastructure.

The monolithic nature of older programs creates its own set of problems. Valuable business logic may be buried deep in a single program and not easily accessible by other applications. Or the source code may be "cloned" multiple times, leading to substantial code duplication and the consequent maintenance burden and potential for inconsistent copies of the logic.

Many older AS/400 applications also intertwine business logic, data access, and user interface code in ways that make it hard to adapt to new data sources or interfaces. Such programs often grow and morph over many years, with different programmers making revisions until the result is difficult to comprehend and unwieldy to change. For many long-lived programs, each programmer who modifies an application uses coding techniques in vogue during a particular era and often codes with a unique style. As programmers leave the organization, new programmers who inherit responsibility for such programs grapple with new technologies while deciphering idiosyncratic code from a different place and time. Such conditions multiply the expense and risk of adapting legacy code to new business requirements.

Another shortcoming of relying directly on IBM i languages, such as RPG, COBOL, and the proprietary Data Description Specification (DDS), is the lack of multi-platform support. Corporate acquisitions and mergers can almost overnight require applications that have been running on an IBM i to also run on another system or be replaced entirely. Neither alternative is a prospect IBM i IT organizations want to face with legacy applications.

Many IT organizations have recognized they need a more effective approach to application development, both for new applications and to "modernize" legacy applications. Many organizations have experience with "refacing" green-screen applications and realize this technique provides only an interim "modernization" tactic. Without addressing the structural and integration issues of new and legacy code and without better ways to get complexity under control, a development group will find most of the big problems remain.

This is where an enterprise application architecture and the tools to support it come into play. Recall that an application architecture describes how a set of building blocks and principles should be used to design, implement, and adapt applications that fulfill the enterprise's business objectives. Before we look at the key technical elements of sound application architectures, it helps to consider the general business objectives for such architectures: greater agility, lower risk, higher predictability and stability, and higher productivity.

These business objectives may look familiar because one or more of them might be used to assess any proposed software development strategy. The advantage of an architecture-driven strategy is that it provides a rigorous, coherent structure to accomplish these objectives. Note that an IT organization also must address other aspects of software development, including requirements gathering, development methodology (e.g., "agile" development), and project management. For example, an application architecture doesn't necessarily determine the precise sequence of steps to be followed in working with end users during a development project. But it does establish the nature of the end product (the applications) so that all the pieces work together in a way that meets the business objectives.

So, despite the effort that may be required, establishing a sound application architecture is the foundation for regaining control of application development. There are various ways to approach this goal, and your organization will want to take some time to conduct the assessments and carefully consider the decisions I've outlined. However you decide to move toward an architecture-driven development strategy, there's no better time to start than now.

Download the free white paper "The Eight Pillars of An Enterprise Application Architecture" here.