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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online