Choosing the Right Architecture: What It Means for You and Your Business Contents

Flexible Architecture Management: Good for Business, Easier than Ever . . . . . 2 Rikki Kirzner

Model-driven and Pattern-based Development Using Rational Software Architect, Part 1: Overview of the Model-driven Development Paradigm with Patterns ...... 5 Colin Yu

Start Focusing on Architecture--Your Career and Future Depend On It ...... 12 Rikki Kirzner

Quality Governance for Software Organizations ...... 16 Marlene Ellin

Open-source Architected Model-driven Development in the Real World . . . . . 22 Steve Andrews Stosh Misiaszek

Enterprise Application Transformation: Leveraging Your Investment in Proven, Mission-critical Business Applications ...... 36 Georgiann Zaglakas

Flexible, Architecture Management: IBM Resources • Rational Software Architect v7 Good for Business, Easier than Ever • Rational Modeling Extension Finally the process of creating, modifying, governing, finding and reusing for MS. Net development assets is within the grasp of any Eclipse developer. Learn • Model SOAs with Rational Software how you and your organization can easily reuse software to lower soft- Architect: Case study, tools, and the business view ware development costs and improve quality.

By Rikki Kirzner

Reusability has been the holy grail of software development for decades. The growing popularity of Service Oriented Architecture has not only created a renewed interest in software reuse, but in many companies a mandate to reuse code, models, tests, and a host of other software assets and artifacts across the organization and throughout the development lifecycle.

Thanks to today's tools, it is possible to efficiently create, locate, assess, and draw on reusable assets thanks in part to the creation of variable asset repositories that can address the needs of different developer roles and communities and a federation of information among these repositories that makes content available in the right form to the appropriate community.

Employing reusable assets as part of development activities is beneficial to both businesses and developers in a number of ways. First, it facilitates a reduction of redundancy particularly in the area of having to maintain and manage multiple, similar software assets. This works to eliminate the task of maintaining (or even creating) multiple base- lines of code, or other artifacts, such as tests or designs to name but a few.

Second, it improves the overall quality and reduces time spent maintaining the software by virtue of the fact that the development team is using the same piece of code or other artifact multiple times, thereby continuously reworking and enhancing it. With this investment in the code, its quality and value increases which means developers are spending less time creating new (and often redundant) code or maintaining the code

Third, it improves productivity by saving developers the effort involved in recoding redundant routines or rebuilding the same artifacts. If they can quickly find assets they can use and easily determine whether or not what they have found meets their requirements, then developers don't have to spend time creating the same things over and over again. This frees them to work on more important and often more interesting aspects of the project.

Fourth, business managers have fiduciary responsibility as well as a vested interest in controlling the reusable assets in an organization and mapping existing assets to the needs of the business. The ability to understand what assets exist, effectively manage their creation and use, and to establish consistent terminology and verbiage when describing them controls costly mistakes, ensures architectural integrity, and enhances governance across the organization

Now it is easier than ever to handle all these tasks. IBM Rational Asset Manager (RAM) lets you create, modify, gov- ern, find, and reuse any type of development assets, including SOA and systems development assets. It delivers these capabilities through a development-time asset repository that manages assets relevant to development roles, such as technical managers, analysts, architects, developers, and testers. Through classification schemas and asset types it also standardizes and enforces the definition and consistency of terms for any size project.

RAM governs assets as they are submitted. It lets you browse and categorize, assets, provides access control, manages and versions assets, and measures metrics such as activity level in terms of their usage. More importantly, it comes as an easy to install plug-in for your Eclipse development environment and leverages and builds upon the skills you already have.

The RAM plug-in inserts new tasks into Eclipse and lets you create, use, or reuse code. You don't have to discard any tools your organization is already using. Assets can be versioned through integration with tools you already use- -Rational ClearCase (CC), and CVS. The Rational ClearQuest integration provides asset defect tracking and asset review customization. The WebSphere Service Registry and Repository integration provides traceability of services from development into runtime.

RAM wraps a collection of files (either from the file system, CVS, or CC) with metadata, identifies it as an asset, and then manages it. When an asset needs to be changed or updated, RAM notifies the appropriate person through these tools and provides the information required to retrieve the asset, fix or update it and check it back into the repository using the tools with which you are already familiar.

RAM is targeted to specific kinds of users, namely in the development space. Before these users can start using RAM, a sequence of events must be completed by an administrator to set up the repository. In brief, an administrator configures one or more development communities in RAM. Each RAM development community is targeted for a specific audience with users, roles, and their permissions. Other items to be configured include asset types and classification schemas that are relevant to the target users.

A RAM development community can also be configured with a connection to one or more WebSphere Service Registry and Repository service registries. WebSphere Service Registry and Repository is targeted towards users who want to use deployed service interfaces. The RAM software synchronizes with the WebSphere Service Registry and Repository software to coordinate the development of service assets (code, models, test, etc.) and related metadata with the interfaces of deployed services.

For example, the RAM administrator may configure one connection to a WebSphere Service Registry and Repository test registry, and another connection to a WebSphere Service Registry and Repository SOA registry. Each connection gets information such as the address to the host, which port to use, the WebSphere Service Registry and Repository login credentials, as well as the name of the owner of the assets. RAM software will allow service asset artifacts to be published to the WebSphere Service Registry and Repository system when the appropriate or qualifying conditions are met.

With the repository configuration prepared, the administrator and developers populate the repository with reusable software assets. The repository can then be used to show you what it contains and to reuse the assets. While RAM is the primary source of information about many kinds of development assets, you can track various references to WebSphere Service Registry and Repository service interfaces for more detailed information about services and other related runtime information. Simple to Install and Use

RAM is installed into Eclipse by pointing to the location of the Eclipse RAM Update Site and clicking on it to select the plug in and start the download to Eclipse. After the download is complete and you restart Eclipse, RAM is ready to be used. At that point Eclipse will identify the different perspectives you prefer to use, select the appropriate views, and add them to where you normally work. You never have to leave your favorite perspective to access the assets in RAM.

Suppose, for instance that you are working in a Java perspective and have one view called 'search results'. Let's further suppose that you need to access a logging component. You would do a keyword search on the asset metadata or inside the files of the asset by entering the word, ”logging”. This will return a result list back to you containing all the assets containing that keyword.

Double click on any asset you are interested in learning more about to find the one that is best suited to your needs. This brings in all the metadata about the asset so you can view its relevant content. You can find out the asset's

3 © 2007 Jupitermedia Corp. Choosing the Right Architecture: What It Means for You and Your Business contents, read the discussion thread about the asset, see how other developers ranked it, and view the statistics showing how often it was downloaded. This level of detailed information helps you decide whether or not you want to download the asset.

RAM knows where the asset is stored so you only need to tell RAM the target where the asset needs to be downloaded. RAM relies on your source control system (Rational ClearCase, CVS, etc.) to manage the versions of the source files of the assets. It checks out and downloads into your workspace all the appropriate files that comprise the “logging” asset you selected.

RAM recognizes when any change was made or new asset was created so when you submit that asset back to the repository, it will alert you that a new version has to be created. Once you approve the version update, RAM will submit the file(s) into the repository where the asset is now subject to all the governance activities that are required before the asset can be approved for use and viewed by other developers

The governance activities will depend on the review process established by the RAM community. Some communities may have many levels of reviewers from business analysts and project managers to the senior programmers on a particular project. Others may just need to be approved by the project manager. Since this information was originally configured into RAM, emails are automatically sent to the appropriate people who need to be involved in the review process.

All the activities that have to be performed on the asset can be viewed in a web-based user interface. When the asset is finally accepted (or rejected) the developer who worked on it is notified. If the asset is approved it is placed into the repository where it is available to the people who are allowed to access and use it.

When a new asset is created for the repository, RAM guides you through the step by step process of defining all the attributes and variables established and required by the community.

RAM provides numerous other benefits to businesses and developers including the ability to reduce development cycles and reduce costs. Secure asset tracking, asset management, enforcement of architectural standards and models, as well as storing and providing quick access to information ensures architectural integrity and better communication for globally distributed and outsourced development projects. Governance challenges are improved with RAM's sophisticated discovery and federated search capability across the development lifecycle and secure intellec- tual property sharing.

It's time to look more seriously at governed asset reuse now that IBM Rational has delivered the combination of a unifying platform and collaborative tools to simplify the process of creating, discovering, understanding, and using reusable assets. After all the decades of promises, the reality of software reuse is finally possible.

Rikki Kirzner is a freelance writer and veteran computer industry professional with experience as an analyst and former Research Director for IDC, Gartner Group, and Meta Group and as a Senior Editor with Open Computing Magazine. Rikki covers software, development, open source, SOA, and mobile computing.

Choosing the Right Architecture: What It Means for You and Your Business

Model-driven and Pattern-based IBM Resources • Pattern Solutions Development Using Rational Software • Rational Asset Manager Architect, Part 1: Overview of the • Asset Life Cycle Management for SOA Model-driven Development Paradigm with Patterns

Level: Introductory

By Colin Yu, Development Manager, IBM

First published by IBM at http://www-128.ibm.com/developerworks/rational/library/06/1121_yu/ All rights retained by IBM and the author.

21 Nov 2006

Model-driven development (MDD) is a style of software development where the primary software artifacts are models from which code and other artifacts are generated. Its goal is to improve the productivity and quality of enterprise application development. Patterns play an important role in model transformation and code generation in MDD. This series of articles discusses in detail the Model-Driven and Pattern-Based development paradigm using IBM® Rational® Software Architect, an integrated development environment supporting MDD. Introduction

Model-driven development (MDD) is a new software development paradigm supported and driven by the Model- driven Architecture (MDA) methodology, a software design approach released by the Object Management Group (OMG). MDA provides a set of guidelines for structuring specifications expressed as models, starting from a platform-independent model (PIM), continuing through an appropriate domain-specific language, and then tranforming into one or more platform-specific models (PSMs) for the actual implementation platform. This could be any number of platforms, such as Java™ 2 Platform, Enterprise Edition (J2EE™), CORBA, or .Net, implemented in a general programming language such as Java™, C#, and Python. MDA is normally performed using automated tools, like IBM® Rational® Software Architect. Driven by MDA, MDD focuses more on model transformation and code generation.

However, the code generation-based approach used by MDD has its own downside, due to things like constraints in generated code, insufficiently skilled developers, and tight coupling to the model. When companies commit themselves 100% to code generation, there is little room for tweaking, especially when developers always have to go through their model.

A pattern-based development approach helps solve this problem. A pattern is a solution to a recurring problem within a given context. Patterns encapsulate a designer's time, skill, and knowledge to solve a software problem. In addition, when it is used repeatedly in a number of different projects, a pattern becomes established as a best practice. By designing around a particular design pattern, developers have greater flexibility to control the generated code, which is not constrained simply based on an abstract model.

Furthermore, MDD can automate implementation patterns with transforms, which eliminate repetitive low-level development work and encode technical expertise to improve consistency and maintainability. A modified transformation is rapidly reapplied in order to generate solution artifacts that reflect a change to the implementation architecture.

This article focuses on how to optimize MDD with asset-based development as an integrated development approach. Using this approach, developers first build the object model using the Unified Modeling Language (UML), and then generate the code from that UML model using a code generation tool that utilizes a pattern repository.

UML is an open standard and the de-facto standard for software modeling. UML is a language for specifying, visual- izing, and documenting software systems. UML provides a visual notation and underlying semantics for software models. UML also has a standard machine-readable serialization format, thereby enabling automation. Applying MDD with Rational Software Architect

Reading this information, you have probably realized that applying this development approach requires an Integrated Development Environment (IDE) that can support the following: • Modeling using UML • Patterns infrastructure • Model transformation and code generation • Platform-specific design and development tool and unit test environment

Rational Software Architect is the tool that provides all those capabilities. Rational Software Architect is an integrated design and development tool that leverages model-driven development with UML to create well-architected applications and services. With Rational Software Architect, you can:

• Leverage an open and extensible modelling platform • Acclerate software modeling and design • Automate development processes and maximize asset reuse • Develop application and Web services more productively

The series of these articles is organized as follows:

Part 1: This article, which focuses on an overview of MDD and Pattern-based development approach

Part 2 (to come): The MDD and Pattern-based development approach with Rational Software Architect

Part 3 (to come): A case study UML model

One of the main characteristics of MDD is using models as the key artifacts. A model is a description of a system from a particular perspective, omitting irrelevant detail so that the characteristics of interest are seen more clearly. In MDD, a model must be machine-readable, so that you can access the content of the model in an automated manner. Models must be machine-readable in order for you to be able to generate artifacts. A diagram on a whiteboard may meet the other criteria for being a model, but until you can capture it in a machine-readable manner, you cannot use it within an MDD tool chain.

Software models are typically expressed in UML. UML models hide technical implementation details, so that a system can be designed using concepts from the application domain. Application design is typically carried out using a UML modeling tool such as Rational Software Architect, and concepts relevant to the application domain.

The use of UML models to design software was a well-established practice even before MDD. In most cases, models are used in two ways:

• As sketches that informally convey some aspect of a system

• As blueprints that describe a detailed design that you manually implement.

In MDD, models are used not just as sketches or blueprints, but as primary artifacts from which efficient implementations are generated by applying transformations. In MDD, precisely described domain-oriented application models are the primary focus when developing new software components. Code and other target domain artifacts are generated using transformations designed with input from both modeling experts and target domain experts. Transformation

UML modeling is a valuable technique by itself, but manually synchronizing models and code is error-prone and time consuming. Transformation is the main characteristic that distinguishes MDD from other approaches that use modeling. MDD is concerned with automating the development process so that any artifact, which can be derived from information in a model, is generated. Besides code, the generated artifacts from transformation include but are not limited to the following:

Documentation: In organizations that follow a formal development approach, producing documentation takes a significant amount of development effort. Keeping documentation in line with the implementation is notoriously difficult. When using MDD, documents are generated from models. This both ensures consistency and makes information available within the models that developers are working with on a daily basis, rather than in documents that are difficult to navigate. Documentation can either be generated by tools such as Rational Software Architect's Report Generator, or by a transformation.

Test artifacts: It is possible to generate basic test harnesses (for example, using JUnit) from the information con- tained in software models.

Build and deployment scripts: Using their expertise, build and deployment architects can create transformations to generate build and deployment scripts.

Other models: A system involves many interdependent models at different levels of abstraction (analysis, design, implementation), representing different parts of the system (UI, database, business logic, system administration), different concerns (security, performance, and resilience), or different tasks (testing, deployment modeling). In many cases, it is possible to partially generate one model from another (for example, moving from an analysis model to a design model, or from an application model to a test model). Patterns

Another main characteristic of MDD is capturing expertise. Patterns capture best practice solutions to recurring problems. In MDD, patterns can occur at all levels of abstraction in modeling. For example:

• Architecture patterns • Design patterns • Implementation patterns

Patterns can be composed to produce pattern recipes for solving larger problems and cover best practices for a domain area.

Patterns specify both characteristics of model elements and the relationships between those elements. You can automate patterns so that new elements are created, and existing elements are modified in transformation to conform to the pattern when the pattern is applied to a model.

Patterns improve the consistency and quality of solutions. They do this by automating implementation patterns with

7 © 2007 Jupitermedia Corp. Choosing the Right Architecture: What It Means for You and Your Business transforms in MDD, which eliminates repetitive low-level development work. Rather than repeatedly and manually applying technical expertise when building solution artifacts, the expertise is encoded directly in transformations. This has the double advantages of consistency and maintainability. A modified transformation is rapidly reapplied to generate solution artifacts that reflect a change to the implementation architecture. From business problems to software solutions

Figure 1 shows how a business problem is translated into a software solution with MDD. The business problem is reviewed, and some common business patterns are applied. This partially populates a design model and fills in details of the specific business function under construction. Then, platform independent design patterns are applied to transform the design model into runtime-independent components. Following that, a runtime platform is selected, and runtime-specific implementation patterns are used to generate the artifacts.

Figure 1. Using MDD to translate a business problem into a software solution

(Source: IBM Rational)

Benefits of using MDD with Patterns

The software development industry has realized quite a lot of benefits by adopting MDD with Patterns. Some significant ones include:

Increased productivity: MDD reduces the cost of software development by generating code and artifacts from models, which increases developer productivity.

Increased reuse: MDD is especially powerful when applied at a program or organization level. This is because the return on investment from developing the transformations increases each time they are reused. The use of tried and tested transformations also increases the predictability of developing new functions, and reduces the project risk

(since the architectural and technical issues have already been resolved).

Improved Maintainability: Technological evolution leads to solution components becoming legacies of previous platform technologies. MDD helps to solve this problem by leading to a maintainable architecture, one in which changes are made rapidly and consistently, enabling you to migrate components more efficiently onto new technologies.

More Flexibility: High-level models are kept free of irrelevant implementation detail. Keeping the models free of implementation detail makes it easier to handle changes in the underlying platform technology and its technical architecture. Changing the technical architecture of the implementation is accomplished by updating a transformation. The transformation is reapplied to the original models to produce implementation artifacts following the new approach.

Consistency: Manually applying coding practices and architectural decisions is an error-prone activity. MDD ensures that artifacts are generated consistently

Improved communication: Models omit implementation detail that is not relevant to understanding the logical behavior of a system. Models are therefore much closer to the problem domain, reducing the semantic gap between the concepts that are understood by stakeholders and the language in which the solution is expressed. Models also facilitate understanding and reasoning about systems at the design level. This leads to improved communication about a system.

Retain expertise: Projects or organizations often depend on key experts who repeatedly make best practice decisions. With their expertise captured in patterns and transformations, they do not need to be present for other members of a project to apply (and benefit from) it.

Lower risk: When using an MDD approach, early application development is focused on modeling activities. This means that it is possible to delay the choice of a specific technology platform or product version until a later point (when further information is available, thus reducing the risk). Lessons learned

MDD is a sound development methodology. However, industry feedback indicates that not all the projects using MDD were successful. This was generally due to several factors:

• Poor project selection • Insufficient planning • Lack of necessary experience and skills

To help you gain the most benefits from MDD, the following are some lessons we have learned from our past projects.

Select the right candidate projects: MDD is especially powerful when applied at a program or organization level, because the return on investment (ROI) from developing or buying the transformations increases each time they are reused. A good candidate project should also have well-defined architecture and repeatable patterns of behavior, so that those patterns can be abstracted to capture the expertise and be used in the transforms.

Consider the additional cost: You may need to consider the cost of developing or buying transformations, but careful cost planning will ensure that there is an overall cost reduction in the long run.

Make small wins: In many organizations, a new approach is greeted with some skepticism until it is proven to work. If this is your first project that uses the MDD approach, it is advisable to split the development of the MDD tooling into a number of iterations. Subsequent iterations build on the experience you gain, allowing you to support a

Develop the right skills: MDD requires architects and developers to be familiar with UML and the IDE for MDD. Building these skills within the team may take some time at the beginning, which leads to project delay. However, with the same project team, subsequent projects will be much smoother. If this is your first project that uses MDD, bringing in experts to jump-start the team is a good choice.

Always think about reuse: The MDD tooling built for your project will have been used many times by the application developers while they are generating artifacts for the business application. It is also possible that this tooling could be reused on subsequent projects. Always thinking about reuse in a bigger context will benefit your organization significantly in a long run.

Select the right development tool: Having the right weapon with you will ensure that you are getting the maximum value from MDD. The project team (including the project manager, business analysts, solution architect, developers, and testers) should evaluate and validate the development tool being used. Summary

Part 1 of this series lays out the picture of the model-driven and pattern-based development paradigm. In summary, MDD unlocks the potential of patterns to create well designed solutions, and patterns provide the content for MDD. Resources

Learn • Model-driven and pattern-based development using Rational Software Architect, Part 2- Model-driven development tooling support in IBM Rational Software Architect: Part 2 of this series..

• Learn about reusable assets, recipes and patterns in this developerWorks article.

• Learn about SOA at the New to SOA and Web services developerWorks page.

• Stay current with developerWorks technical events and Webcasts.

• IBM Rational Software Architect product page: Find technical documentation, how-to articles, education, downloads, and product information about Rational Software Architect.

• Visit IBM's Pattern Solutions and find out what IBM is doing around patterns and reusable assets.

• In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena.

• Browse the technology bookstore for books on these and other technical topics.

Get products and technologies • Download a free trial version of Rational Software Architect v7.

Discuss • Rational Software Architect, Data Architect, Software Modeler, Application Developer and Web Developer forum: Ask questions about Rational Software Architect.

• Check out developerWorks blogs and get involved in the developerWorks community.

About the author Colin Yu is the development manager of the repository for reusable assets to support Asset-based Development with the Rational Software Development platforms. His prior jobs include On-demand software development, work as a solution architect of the WebSphere Business Integration platforms, and WebSphere Studio development. You can reach Colin at [email protected].

Start Focusing on Architecture--Your IBM Resources • Rational Software Architect v7 Career and Future Depend On It • Rational Modeling Extension As outsourcing wreaks havoc on professional programming careers, and for MS. Net development grows increasingly more complex, it is time to consider • Model SOAs with Rational Software expanding your future opportunities by focusing more on software archi- Architect: Case study, tools, and the business view tecture. Here is a roadmap for expanding your skills while staying within your comfort level.

By Rikki Kirzner

Increasingly, companies report that the globalization of distributed software development is growing more complex, making software projects harder to manage. Even when software development is still performed in house, most development operations are typically globally distributed. Concurrently, business processes and technology are growing more and more intertwined, further increasing complexity in both distributed and offshore projects.

To control costs and decrease development time as they try to cope with all these changes, companies are driving their domestic and outsourced developers to produce high quality sophisticated software applications faster than ever using development environments that have become exceedingly complex. Consequently, it has become virtually impossible for developers to keep pace with today's development challenges and escalating sophistication without resorting to a higher level of abstraction.

At its most basic level, abstraction is achieved using a higher level programming language. However, the specificity and detailed nature of code (Java, C/C++, etc.) doesn't convey the bigger picture of large, sophisticated development projects. When this type of software project is spread out across different time zones, languages, and cultures, it becomes so difficult to manage that the only practical solution is to logically break up the development effort and assign different parts of the system to specific development teams in various geographical regions. To do this successfully requires an even more abstract view of the software design, dependencies, and all the things that comprise the project--the software architecture view. Architectural Skills Increases Your Value to Your Company

Why should you care about architecture? The answer is simple--your career and your future depend on it. Architecture is growing in importance affecting what you do, how you work, and where you work, relentlessly influ- encing your career and opportunities for future employment. But there are many reasons to focus more attention on architecture apart from saving your career.

Outsourcing and offshoring deliver good programming skills at a lower cost using cheaper labor. Developers certainly recognize the serious impact this has had on the availability of mainstream, domestic, programming positions. Although most companies have not completely eliminated all programming jobs, there will continue to be fewer jobs available. One of the ways senior managers decide what developers they are going to keep and which ones they are going to lay off is determined by the additional skills a developer may possess.

Do you feel threatened by job shifting? You certainly can increase your value to your employer if you can relate software design and development to the intrinsic needs of your business and customers--something most outsourced personnel can't do. One way to do that is to become more focused on architecture than on implementation.

For starters, any attempt to offshore and outsource any project without considering the architecture is a potential recipe for disaster due to the cultural and language barriers which lead to communications problems and misinter- pretation of the specifications. In addition, the logistics of managing a project across different time zones and coun-

12 © 2007 Jupitermedia Corp. Choosing the Right Architecture: What It Means for You and Your Business tries can be quite difficult, particularly when your outsourcing company is subcontracting part of the work to another company in another country. Working at the architectural level provides a language of discourse that is closer to that used by business analysts and others. In other words, it is easier for a business analyst to see how their requirements map to architecture than to source-level code.

The best part is that there are a variety of tools and technologies available to help you focus more on architecture and requirements and less on implementation. The tools are structured with functionality to make this transition and learning curve as painless as possible while keeping you within your comfort level. Some tools contain the languages of architecture such as business process modeling language or unified modeling language (UML). Even rudimentary tools such as Visio or PowerPoint let you understand your project from a more abstract, architectural context.

Today's powerful, highly automated design and construction tools go far beyond basic IDE to support development using high level architectural languages instead of programming languages. These are especially well suited for those companies who can't outsource for one reason or another, but can not keep staffing using expensive domestic programmers. Productivity gains are achieved because a fewer number of people can work more efficiently than a team of software engineers by using these multi-function and highly automated tools for development. How to Start Focusing on Architecture

The first thing you can do is learn more about architecture and prove to your management that you are ready, will- ing, and able to leverage new technology skills that enable you to be more productive and valuable to your organization. A good place to start is to review these materials:

• Evolution of Developer Skills Is Essential for Job Survival • eBook: The IDE as a Development Platform • Find the Right IBM Rational Analysis Design and Construction Tools for Your Project • IBM Rational UML Resource Center Tools to Assist You Each Step of the Way

You probably are already familiar with IDEs containing some level of design capability and/or visual modeling. You certainly have used wizards to automate some of your development tasks. You might even be familiar with IBM Rational Application Developer (RAD) which has built-in code-level architecture features. RAD is built on Eclipse and extends the Eclipse framework. It is positioned primarily for both visual and code-oriented developers but won't alienate you with lots of UML model driven capability. However, if you want to think like an architect and improve your skills by working in a more abstract (and architectural) view of your code, you should explore RAD's UML visu- alization capability.

RAD allows existing code to be rendered in UML for developers who just don't know the UML language. Many developers find it easy to transition from code to code level modeling using RAD. RAD utilizes class and sequence diagrams and also includes code analysis functions and automated test and deployment tools.

RAD lets you traverse source files using the pictorial view and if you make changes to the code, the diagrams update automatically. You can also edit the diagram to update the code because RAD maintains an isomorphic or 1:1 relationship between the UML and code. RAD is a good first step toward thinking and working at an architectural level. However, if you are using code rendered into UML you are just looking at a pictorial view of the code which means you are still editing at the code level Taking the Next Steps on the Road to Architecture Architects have to think more abstractly--at levels that don't immediately have any relationship to code. Architects work between the business requirements that drive the business and the implementation levels that are a reflection

13 © 2007 Jupitermedia Corp. Choosing the Right Architecture: What It Means for You and Your Business of the programming decisions that are executed into code. Achieving these skills requires you to learn how to work with basic UML modeling.

Since the industry is also becoming more service oriented in its design and implementation of architecture and software, you should learn as much as you can about service oriented architectures (SOA) because SOA combines reuse thinking with business-level abstraction to support the creation of reusable components. This enables software to be built using components in a manner similar to the way engineers build hardware.

There are design and construction tools that support your efforts to work at a more abstract level and also facilitate the creation of SOA solutions. One example is IBM Rational Software Architect (RSA) which leverages model-driven development with UML, letting you create well-architected applications and services.

While RAD eases the transition between the architecture, it only serves the code-level of modeling and the model- to-code and code-to-model transformations. RSA, on the other hand, includes all the features of RAD to give you an integrated design and development experience and adds model-to-model transforms, as well as a powerful patterns development capability and an architectural analysis capability.

Architects and SOA developers use patterns to accomplish many of their development tasks, since the essence of SOA is reuse and the mechanism of reuse is design patterns. Patterns let you capture domain knowledge, best practices, and design expertise to improve productivity, efficiency, and quality while automating and minimizing the mundane and mechanical aspects of software development. Patterns can also represent known problems and situations in business domains.

Pattern implementations are one of the most powerful software engineering tools you can use to improve development and productivity in your organization. Their use eliminates tedious, error-prone tasks, minimizes complexity and confusion, improves governance, and increases the overall quality of any type of software project. They allow you to respond more quickly and cost-effectively to changing business conditions.

As any software architecture evolves, an architect takes the revised requirements and creates an analysis level model that reflects the requirements but doesn't yet reflect the implementation. Using RSA, an architect first creates an analysis-level model. A subject matter expert like an analyst validates the representations captured in analysis- level model diagrams to ensure that the architecture meets their requirements.

There are patterns that specify how you transform an analysis-level model into a design-level model (known as a model-to-model transform). Once you provide sufficient detail in your design model, you can apply model-to-code transforms automating much of the implementation work.

RSA lets you create and use pattern implementations and model transforms. RSA enables you to leverage abstraction using multiple models to capture the relevant aspects of a solution. Transformations allow you to automate how you move between the levels of abstraction. RSA also enables you to specify high-level aspects of a system created in a model and generate a larger percentage of the solution automatically.

If you need to model, but don't want all the specificity required for code generation, consider using IBM Rational Software Modeler (RSM). RSM is a modeling-only subset of RSA and extends Eclipse to enable architects, systems analysts, designers and others to specify and communicate development project information. It supports the same level of modeling with UML version 2.1 as RSA, supports patterns and model-to-model transforms, and has the same flexible model management for parallel development and architectural refactoring. RSM is useful for situations where automated modeling is needed but the model-to-code transformations are done more manually.

Hopefully this article has been able to pave a professional roadmap you can follow. It will take you from the abyss of job loss due to outsourcing to the wealth of opportunities that await you by focusing on architecture. As you follow this roadmap keep in mind that there are developers who are working at levels of abstraction even higher than those

14 © 2007 Jupitermedia Corp. Choosing the Right Architecture: What It Means for You and Your Business of a software architect. They are in the business community working with databases, operation deployment, hardware and process servers, focusing their efforts on enterprise architecture, which is a subject for another paper entirely.

_INFRASTRUCTURE LOG _DAY 62: We don’t have the tools to leverage open standards like Eclipse™ and Linux. We have zero support. We need to do something but don’t know where to start. _Gil’s on it… He’s forming a developer“support”group. _DAY 64: This strikes a chord: IBM Community Edition products along with tools and support from Rational. They’re based on open standards and give us what we need for business-critical apps. And IBM software and systems support a wide range of development styles and programming languages. _We have all the support we need now. And three flutes.

Get started with our Community Edition software at: ibm.com/takebackcontrol/open

IBM, the IBM logo and Rational are registered trademarks of International Business Machines Corporation in the United States and/or other countries. ©2007 IBM Corporation. Eclipse is a trademark of Eclipse Foundation, Inc. Linux is a registered trademark of Linus Torvalds. All rights reserved. Ad No.: SGP-07-3 Alt 1 SAP No.: IMN.IMNSDM.07036.K.011 Ad Title: TBC-D&TA-Open for Business (Support Group) This advertisement prepared by: Ogilvy & Mather ARTWORK SHORT To appear in: Standard Page Size: Full-Page Color: 4/c Bleed: 8.75 in x 11.25 in Trim: 7.5 in x 10.5 in Safety: 7 in x 9.75 in Scale: 1:1 Actual Trim: Same as Trim Gutter: None Creative Director: None Art Director: A. Gray Copywriter: R. Jamieson Account Exec: None Print Producer: M. Piscatelli Traffic:R. Fuller Engraver: None REDWORKSNEWYORK Filename: IMN_SDM_07036_K_011_AD_1D2.indd

Document Path: Redworks:Volumes:Redworks:Print:H-N:IBM:IMN.IMNSDM.07036.K.011:Mechanicals:IMN_SDM_07036_K_011_AD_1D2.indd Created: 4/24/07 8:00 PM Current Date: 4/27/07 3:41 PM Operator: am Proof: 2 Galley: 1 Output: 2 Fieries, CD, pdf Client: IBM Corporation Keywords: None Print Scale: 100% Fonts: Osaka, IBMHelvetica2004, IBMHelveticaCond2004, IBM Osaka, DIN Swatches: C=5 M=4 Y=4 K=0, Paper, Black, C=100 M=0 Y=0 K=0 Images: Kumbaya_30Jan.jpg (RGB; 192 ppi), IBM_logo®_K.eps, Rational_.375”.eps Choosing the Right Architecture: What It Means for You and Your Business

Quality Governance for Software IBM Resources • Ensure High Quality SOA Applications Organizations • Learn How to Test Web Services for SOA Quality Level: Introductory

Marlene Ellin, Reporter, The Rational Edge ezine

First published by IBM at http://www.ibm.com/developerworks/rational/library/dec06/ellin/index.html All rights retained by IBM and the author.

15 Dec 2006

from The Rational Edge: The article describes the benefits of the IBM Rational Software Delivery Platform, which helps companies create a quality governance framework that accommodates organizational transformation needed for today's technological advances.

In a series of frescoes lining the walls of the Palazzo Pubblico in the Tuscan city of Siena, fourteenth century Italian painter Ambrogio Lorenzetti depicted the effects of good and bad government on urban and country life. Those who enjoy the blessing of good governance go about their daily business within a landscape of peace and prosperity; the unfortunate souls living under bad governance suffer the evils of war, disorder, and mayhem.

The effects of good and bad governance have not changed over the centuries, and today they apply to the world within a business as well as the civil realm. A well-governed workplace makes employees happy and productive. But extending far beyond policies and procedures that benefit employees, good governance is what keeps a company profitable and competitive. It establishes oversight for an organizational structure and a set of business processes that allow people to work efficiently and manage the quality of what they produce.

On December 5, 2006, the IBM Rational organization released version 7 of its desktop tools and launched a comprehensive strategy for quality management, based on the best practices and tools offered in the new release. This article presents an overview of the quality management strategy, describing its benefits and explaining the vision behind it. Governance in a software context

Nowhere is effective governance more critical than in the organizations that deliver software and software-intensive systems. Increasingly, companies depend on software to run their business processes; many also incorporate software into their products, whether they produce it themselves, outsource its production, or buy it from another supplier.

For a software-dependent company to succeed, it must have applications that consistently perform well in a runtime environment -- that are high-quality and thoroughly tested before deployment. This requires agile business processes for software delivery that are adaptable to many different types of projects and speed time to market, rather than slow- ing it down. In turn, such a process must be governed by an adaptable framework consisting of rules, best practices, and continuous management visibility into project progress and alignment with business requirements.

Good governance is different from good management, which is often tactical and reactive rather than strategic and proactive. Governance structures are repeatable touchstones that ensure that both providers and clients will set and live up to expectations. As IBM Distinguished Engineer Kurt Bittner points out, governance establishes and enforces accountability. It should measure things that matter and hold team members accountable for things that will affect overall team results.

The IBM Rational quality governance vision

Of course, quality is one of the things that matters most for today's software and software-intensive systems. Quality has an enormous impact on team results and customer satisfaction, and the IBM Rational organization has long recognized the need to make quality an organization-wide concern. It has a long, proven record of providing automated capabilities to oversee testing, measurement, change management, error correction, and other quality-related activities.

Quality governance is a discipline within a larger governance environment for software and systems delivery. One component of quality governance is organizational and structural, providing chains of responsibility, authority, and communication that enable a workflow for applying quality measures. The second component relates to measurement: rules, policies, and control mechanisms that enable people to assess product quality and progress. This is where IBM Rational has always focused its attention.

For more than 25 years, a desire to help clients create a comprehensive quality management environment for software development has driven Rational's product strategy. One of the best practices embodied in the Rational Unified Process®, or RUP®, is iterative development, and quality management is an underlying principle of this approach. Iterative development emphasizes continuous alignment with changing business requirements, early testing, and deep client involvement in prototyping and beyond.

Through internal development, strategic acquisitions, and harvesting best practices from client engagements, Rational has continuously enhanced its clients' quality management capabilities. Via integrations with IBM WebSphere and Tivoli technology, the Rational Software Delivery Platform now provides automated capabilities for infusing quality into every phase of software and systems delivery -- from component testing by developers through build and actual production environments. These capabilities represent a flexible framework that fosters agility, not rigidity. In the words of IBM Distinguished Engineer Grady Booch, good governance "...promotes predictability and repeatability but still allows cre- ativity to flourish."

With the Rational Software Delivery Platform, creating an effective structure for governing quality management does not require a total organizational transformation. Tight product integrations and an open source ecosystem make it relatively easy and affordable to introduce Rational products into a workplace that employs other quality management products and processes -- and protect previous IT investments. As the quality governance framework evolves, individual technologies may keep their identity, but will naturally begin assuming organizational characteristics.

Solutions to ensure software quality

Built on the IBM Rational Software Delivery Platform, our testing solutions enable tighter management, better planning, and improved data sharing for all team members. To help you make confident go-live decisions and build high-quality enterprise applications, we offer solutions for performance testing, functional and regression testing, manual testing, developer testing, and test management. The relationship of these testing roles and associated IBM Rational products is illustrated in the figure next page.

With our solutions, quality assurance teams can easily manage and address issues with application functionality, usabili- ty, reliability, scalability, and performance. For more information on these testing products, see http://www-306.ibm.com/software/rational/offerings/testing.html

(Source: IBM Rational)

Benefits of quality governance

Introducing quality governance into a software organization -- establishing chains of responsibility as well as instruments and processes for quality measurement and control -- can produce significant business results. Let's consider the key benefits.

Faster time to market/value

Although some organizations fear that quality measures will slow their software delivery schedule, a quality governance framework that produces continuous insight and data throughout the delivery lifecycle actually helps to accelerate production readiness and sustain high performance after the software is deployed.

• Component development teams can test and eliminate defects before build. This may indicate a need for feature alterations early on, when changes have a relatively small impact and require less time and effort to execute.

• By discovering, resolving, and documenting problems early, teams can navigate more quickly through later development phases. For example, the production team can use quality data from testing performed earlier in the delivery lifecycle to quickly locate and correct root causes of problems. In addition, teams can avoid wasting deployment and post-deployment testing time on bad builds -- and apply their efforts to more productive and satisfying work.

• Development teams can use post-production data to redefine test cases, detect more pre-production defects, and guide feature modifications for the next release. In other words, the organization can control quality process es across and between software and systems delivery cycles to achieve continuous quality improvement.

Quality governance is the way to counter the prevailing attitude in many software organizations, summed up in Meskimen's law of quality: "There's never time to do it right but always time to do it over." In fact, it is better quality that

Greater levels of productivity and innovation across software and systems delivery teams

If governance measures are in place to ensure that your organization delivers only high-quality products, then once those systems are in production, teams can focus their attention on new projects rather than bug fixes. According to the National Institute of Standards and Technology, software organizations currently spend 80 percent of their resources on error correction and maintenance. Quality software allows teams to spend more time thinking about ways to add value and create useful details rather than making corrections.

Greater customer satisfaction

With a well-governed, automated approach to quality, software managers can constantly monitor coordination between requirements and execution. Meta Group reports that most customer dissatisfaction stems from poor understanding of requirements. Rational offers strong support for keeping software products aligned with requirements, including automated tools for defining and tracking requirements throughout the development and delivery lifecycle, as both requirements and features evolve and change. Other products in the Rational Software Delivery Platform help organizations define a requirements-based business process for application development and then gather real-time information from multiple environments to analyze process performance.

Risk reduction

Controlling the quality processes across and between software and systems delivery cycles gives companies many ways to lower risk.

• By conducting quality progress checks throughout every delivery phase, managers can ensure that whatever deliverable a team is working on will meet exit criteria and be ready for primetime production.

• With continuous, integrated automation, each activity team (e.g., test) can leverage artifacts from previous activities or phases (e.g., build). This improves efficiency, productivity, and workflow; it also creates auditable trails, provides process validation, and reduces the risks of error and failure.

• With metrics that enable them to compare apples to apples, managers can more easily direct their teams to pin point and eliminate sources of risk. For example, by comparing code churn from phase to phase, they might spot an underlying problem if the pace picks up in one phase. Likewise, by comparing performance data from release to release, they can assess whether the quality measures they applied resulted in real improvements.

• Upcoming releases of Rational products will provide common log and tracing capability to help accelerate the location and repair of problems that occur during the application development process. Using these products across the various software and systems delivery phases and activities will help teams identify root causes via the systematic consolidation, correlation, and analysis of log events, using a common "language."

Market advantage

The software marketplace is plagued by low-quality standards and project failures. Companies can realize substantial competitive advantage by consistently producing high-quality software in a timely way. According to the Cutter Consortium, nearly a third of organizations say they release software with too many defects; an even greater proportion say they lack an adequate software quality assurance program. Against such a landscape, companies with effective quality measures can establish a reputation for having quality internal systems and producing high-quality, reliable software. Based on this, they can build and strengthen brand loyalty -- even in markets that are increasingly commoditized and brand agnostic.

Cost efficiency

Employing a governance structure that cultivates an internal culture of quality can help software organizations realize substantially better returns on their investments. Instead of using up 80 percent of development time on identifying and correcting defects (as noted above), organizations can use that time to come up with innovative ideas and products. As industry expert Philip Crosby has noted, all of this is "free" once you do the organizational transformation necessary to put a governance structure in place, along with a well-defined process that gets unanimous buy-in from team members. When you can integrate and automate processes that establish and encourage quality from beginning to end of the delivery cycle (i.e., from requirements gathering through delivery), you already have a foundation in place to support your project schedule and cost restraints. Ultimately, you have an organization in which developers can focus on value- added features and quality across the lifecycle -- and managers can constantly evaluate end-user feedback to invigor- ate the product line and satisfy repeat customers.

Better quality of life for managers

Among all the measures companies take to retain good employees, none is more effective than allowing them to do their job without experiencing high stress and having to agonize over details. Managers who work within a software organization with quality measures in place do not have to constantly feel that their job is on the line -- as they weigh the consequences of shipping products with known defects. In addition, the consistency and predictability that a quality framework provides allows them to continuously move their projects forward instead of stopping to re-scope and make corrections. They are able to meet deadlines and use project milestones for their intended purpose: to assess the project's value and progress, ensure it is aligned with business strategy, and decide whether it is worth the investment in time and money required to move forward toward completion. Accommodating technological change

Rational has long recognized that governing software quality is not just a managerial concern; it has a strong impact on the daily lives of everyone within a software delivery organization, as well as on business results. Today and in the future, Rational's mission is to help clients support a quality governance framework that is broad and flexible enough to accommodate the organizational transformation that inevitably comes with technological advances. Along with this mission comes the recognition that such transformations are typically evolutionary; Rational's Software Delivery Platform enables companies to achieve significant levels of success by implementing products and processes in a selective, iterative fashion.

Most recently, the Rational organization has developed and assembled the tools and service capability required to gov- ern quality in organizations that have adopted service-oriented architecure (SOA). These architectures necessitate changes in command chains as well as software development practices that many organizations are still trying to sort out and evaluate. The IBM Rational integrated platform coupled with deep process expertise can help companies build an automated SOA quality governance structure that clarifies responsibilities, ensures application integrity as well as alignment with business strategy, and protects investments -- both now and in the long term. These capabilities will serve as a model for future quality offerings that enable software delivery organizations to take full advantage of powerful new technologies.

For more information on the latest release of IBM Rational tools that can help software delivery teams establish a quality governance initiative, see the Rational Software Delivery Platform V7 announcement page at http://www- 306.ibm.com/software/rational/announce/dt/

And to learn more about the IBM Rational strategy for quality management, see the overview at http://www-306.ibm.com/software/rational/offerings/testing.html

About the author

A freelance writer and former senior editor for The Rational Edge, Marlene Ellin has devoted her career to creating content for a variety of business, education, and consumer markets, on subjects ranging from software to international travel. Several of her articles are posted on Parenthood.com and Eons.com. Contact her at [email protected].

Choosing the Right Architecture: What It Means for You and Your Business

Open-source Architected Model-driven IBM Resources • Integrating Open Source into Development in the Real World Your Business • Rational Elite Support for Eclipse Level: Introductory • Open for Business Resource Center

Steve Andrews, President, Fountainhead Solutions Stosh Misiaszek, Director of Strategic Alliances, Number Six Software

First published by IBM at http://www.ibm.com/developerworks/rational/library/feb07/andrews_misiaczek/index.html All rights retained by IBM and the author.

15 Feb 2007

from The Rational Edge: Read how Number Six Software used Model Driven Development techniques to provide a health services portal that realized significant cost and quality improvements.

Competitive success for organizations, indeed even viability, is being driven more and more by how quickly an organization can conceive and deliver new solutions to the market place. This "clockspeed" for development of products is increasing significantly over time and shows no signs of abating.1 It is increasing at an especially fast rate for those organizations for whom software is critical to their success. As a consequence, IT organizations need to produce more business value in shorter timeframes.

As if this weren't enough, the underlying technology for business solutions is continuously evolving. Operating systems, databases, communications protocols, and a host of components that applications are built on are always being upgraded and improved, each on its own independent release cycle. In order for a business to remain competitive it must manage the underlying technology on which its applications are built.

The ever-increasing speed for software development, along with the need to continually adapt to the ever-shifting technical foundations on which software is built, stress the limits of what can be accomplished by most of today's software development organizations No matter how effective an organization is at developing software, it will only remain competitive if it continually addresses the need for speed and the shifting technology issues. A recent Gartner Application Development Summit succinctly summed it up as: IT organizations cannot code their way into the future.2

One way to address this paradigm shift is by approaching software development at a higher level of abstraction and automating a larger amount of the code development. The purpose of this article is to outline a strategy that has been proven to address these concerns and prolong the viability of software development organizations that adopt it. Number Six software is an organization dedicated to improving our customers' ability to develop software. We are committed to leveraging modern software development best practices, as embodied by the IBM Rational Unified Process®, or RUP®, to deliver innovative solutions that optimally address the target organization's business problems. In this paper we describe how we have accomplished that.

We begin by reviewing the concepts of Model Driven Architecture (MDA)3 as well as the Number Six concept of Architected Model Driven Development (AMDD), which is a specialized case of MDA. We then describe Atlas, the open source application development platform, which Number Six developed to automate AMDD. Finally, we present a case study from based on an implementation at a major US-based healthcare organization, where Number Six successfully implemented a health services portal using Atlas to realize significant cost and quality improvement.

Architected model-driven development

This section describes how MDA techniques may be employed to raise the level of abstraction for software development to improve developer productivity, decrease development costs, and increase the future resiliency of applications.

Model-driven architecture

The OMG MDA concept4 provides for the transformation of a platform-independent model (PIM) that describes the business concerns of the application into a platform-specific model (PSM) that describes how the application will be implemented. The target platform is typically described in terms related to the implementation language and a technical framework on top of that. J2EE is an example of a technical framework that consists of a series of interfaces in the Java programming language.

The technical framework provides the essential building blocks for constructing an application. Experience has shown us that simply describing the target platform at the technical framework level is not sufficient. Once the technical framework (e.g. J2EE, .NET, etc.) has been decided, a significant amount of work must be done to define and implement the architectural mechanisms that will be needed to support the functionality of the application being built. In other words, we have to figure out how to best assemble our applications to leverage the technical under- pinnings. Examples of architectural mechanisms include persistency, remote-ability, validation and error handling, and many others. The design of the architectural mechanisms for an application is described in a platform-specific model (PSM).

In theory, any number of transformations can be applied to the same PIM resulting in as many PSMs. A PSM can then be transformed into an executable platform-independent implementation. This allows the application implementation to evolve independently of the business-specific model to adapt to changing technology needs.

MDA with application frameworks

Despite the fact that technical frameworks provide a significant amount of the scaffolding needed to build an application, time and time again we find ourselves designing and implementing application code to best address the architectural mechanisms. Over the years, patterns have emerged that codify these recurring design strategies. One of the better known examples of these are the Core J2EE Patterns.5 These patterns describe how to structure an application to best leverage the underlying technical framework to accomplish the business objectives of the target application.

In many cases, the strategies used to leverage platform services may be reused across many applications, which may automate widely-varying business functions. In fact, these design and implementation strategies can be distilled and reformulated into re-usable application frameworks. Application frameworks serve the purpose of encapsulating the architectural mechanism contracts and common functions for applications that leverage them to realize a set of business objectives. This is the plumbing of an application that needs to be in place for the application to work, but tends to be a drain on development resources at the expense of addressing the business concerns of the customer. There are many application frameworks in the open source and commercial spaces, and many more have been custom-built by organizations that develop applications. The Spring Framework6 is a good example of an open source application framework.

Leveraging an application framework by itself can improve developer productivity since it can do the heavy lifting of the architectural mechanisms and allow the developer to focus more on the business logic that is of value to the user. Additionally an application framework can improve application quality by constraining the places that developers can modify code, preventing them from inadvertently breaking architecturally significant code. The hallmark of a good application framework is that it is rigid where is has to be and flexible where it can be.

Architected Model-Driven Development (AMDD) is a strategy that leverages the strengths of both application frameworks and MDA techniques. The general premise is that a model defines the entities and services of the application, and that model gets transformed to a PSM that is based on a combination of a technical framework and an application framework. In this approach, a large amount of the application code is generated directly on top of the application framework and requires no modification by the developer. By providing an application framework, fewer implementation details need to be determined by the application developer. The net effect is that the application developer can devote more attention to the business logic, and the gap between the problem and solution space is decreased.

Figure 1 depicts the overall concept of AMDD as it leverages application frameworks in conjunction with MDA.

Figure 1: Architected Model-Driven Development

The left side of the diagram in Figure 1 shows the Platform-Independent Model (PIM) as a representation of the business problem. Historically, the application stack shown on the right of the diagram is where the majority of a software development effort is expended.

What the diagram shows is how we can use MDA techniques to transform a technology-agnostic PIM into a platform specific implementation based on a PSM. The top arrow shows that a decreasing level of abstraction results in greater implementation specificity by means of model transformations.

The technical framework, which provides the essential building blocks for creating an application, is made more implementation-specific by layering an application framework on top of it. The actual business logic is encapsulated in the application code that is layered on top of the application framework. The right hand arrow shows decreasing abstraction with respect to the technical implementation. Importantly, the application framework can be leveraged across multiple applications as it is in fact the common functionality, or plumbing, that cuts across business domains. In the AMDD approach, the application code is generated via model transformations on top of an existing application framework, which is based on a technical framework. In theory, any number of application frameworks could be based on a technical framework, and any number of model transformations could be developed to generate application code on top of those application frameworks.

The two arrows together show that the convergence of decreasing model abstraction with decreasing implementation abstraction results in a platform specific, deployable application that maximally addresses the business concerns. The color coding of the diagram shows increasing technical solution specificity on the horizontal axis and increasing coverage of the business problem in the solution space on the vertical axis.

AMDD and the software development lifecycle

While AMDD does provide a significant number of benefits to software development efforts, it bears noting that it is not a silver bullet that eliminates the need for the other software engineering disciplines.

AMDD obviously relies heavily on models and transformations to automate the forward engineering of application code. Since there is such a direct and recurring correlation between the models and the downstream implementation artifacts, there needs to be an increased emphasis on maintaining the integrity of the model. This may actually require the analysis and design activities to take a little longer than in the days when the design was an interim (or worse throw-away) artifact. In AMDD, the PIM, PSM, and a series of transformations is the code, and this makes the models much more important than they used to be.

The need for quality requirements continues to be of paramount concern. In fact, the ability to represent informational needs as entities and coarse-grained business behavior as services in the PIM depends largely on unambiguous requirements. It is actually possible that employing AMDD will force increased rigor around the requirements discipline. All too often "fuzzy" requirements wind up getting modeled improperly and the resulting code does not satisfy the user's needs. In the case of AMDD, the effects of poor requirements are propagated to the application code by means of model transformations instead of manual human effort.

In order to apply AMDD, it is essential that the requirements be modeled in a PIM; otherwise the code simply cannot be generated. AMDD is more applicable to some problem domains than others, and so it is important to apply due diligence during the Inception and Elaboration phases to validate the use of this approach on any one project.

The implementation discipline is most significantly affected by the AMDD approach due to the amount of the code that may be generated as opposed to having to hand code it. If the requirements and analysis and design activities are performed correctly and the application framework takes care of the architectural mechanism implementations, the developer's job revolves largely around implementing business logic. Depending on the fidelity of the model, much of the business logic may be generated as well. For example, if an operation can be modeled completely as an activity diagram there should be no reason why that operation implementation could not be generated. Unit testing is still important, and it is possible to generate unit test harnesses by applying a series of transformations to the model as well.

The test discipline is still very much needed. Using proven application frameworks will decrease the incidence of "plumbing" defects; however, the business functionality still needs to be tested. Identified defects may potentially need to be resolved in the model, in the manually developed business logic code, the model transformations, or some combination of these. Atlas

Based on experiences across a number of software development engagements, Number Six Software has developed an AMDD framework that can be used to facilitate the rapid development of applications based on a single PIM. Atlas is an open source project that is continually evolving to meet the needs of application developers world- wide.

Atlas implements AMDD by providing the following capabilities: 1. A standard way to represent a platform-independent model; 2. The ability to define an application framework that defines the architectural mechanisms. Any application framework can be supported. Two examples include Spring and the Atlas-Java application framework described below; 3. The ability to define application framework plug-ins that provide specific implementations of architectural mechanism interfaces. Examples of plug-ins for a framework include Hibernate7 for persistency, Struts8 for a model-view-

25 © 2007 Jupitermedia Corp. Choosing the Right Architecture: What It Means for You and Your Business controller in the presentation tier, Axis9 for exposing services as web services, and so on; 4. A toolkit for defining templates that can transform the PIM elements into the platform-specific implementation based on the application framework and plug-ins; 5. A build lifecycle that incorporates the source code generation from the PIM as a precursor to source compila- tion.

Figure 2 Atlas AMDD Atlas models

Atlas provides a common way to model the primary concerns of an application: the maintained state (entities) and the exposed behavior (services). This model is also known as the application metadata. It is defined using XML, and it is based on the OMG Meta-Object Facility (MOF)10 and the Unified Modeling Language (UML).11

For the initial versions of Atlas, the decision was made to use the XML metadata-based approach in order to force more rigor in adhering to the modeling conventions required by the Atlas transformation engine. Model validations at this point are primarily syntactic in nature and revolve around validation against a series of XML Document Type Definitions (DTD). In the future, UML profiles and associated model validations may emerge in order to support visual modeling.

The primary difference between Atlas models and those of other MDA solutions is one of abstraction. One of the goals of Atlas is to unburden the application developer from as much of the underlying architectural mechanisms as possible. This means that the majority of an application is defined in the PIM, and business logic is developed largely "between the braces" of generated template methods. The PSM is largely defined in the transformations from the PIM to a platform-specific implementation (PSI). These transformations are made significantly less verbose and less complicated by specifying target implementations that are based on application frameworks that take care of most of the heavy lifting of the application.

Some MDA solutions perform transformations on a PSM to generate a PSI, meaning the modeler is required to have an in-depth understanding of the architectural mechanisms. These tools also may provide robust round-trip engineering capabilities between PSM and code. Borland Together12 is an example of this kind of development environment. Others like AndroMDA13 involve code generation from models that are hybrid PIM and PSMs. For example, one way to transfer entity information across application tiers is to use a transfer object representation of the entity. In AndroMDA, both the platform-independent entity and the platform-specific transfer object are modeled.14 In Atlas, this same pattern can be implemented with a more concise PIM that does not require modeling the transfer object separately. Based on the conventions established by an application framework, transformations can be developed that leverage the appropriate representation (transfer object, business object, etc.) of the entity in the generated code.

Other MDA tools provide a clearer delineation between the PIM, PSM, and PSI than even Atlas does. One example is Compuware's OptimalJ15, which is not an open source product and currently only supports generation of J2EE- based applications.

Entities

Entities represent things that have persistent state in an application. In a UML PIM, entities are key abstractions represented as classes with the <> stereotype. Figure 3 depicts the UML representation of a sample entity with two fields.

Figure 3 Sample Entity -- UML Representation

The Atlas metadata facility provides the ability to model the same entity using well-formed XML. This metadata allows for specification of additional information about the entity such as the names of the database table and columns that the entity state will be persisted in. Figure 4 shows the Atlas metadata representation of the sample entity described above.

Figure 4 Sample Entity -- Atlas Metadata Representation

All the standard association types may be represented in the metadata as well. These include one-to-one and one- to-many composition associations and many-to-one and many-to-many aggregation associations.

Services

Services that expose the discrete business functions of an application are also modeled using the Atlas metadata facility. In the UML PIM, services are modeled as key abstraction classes with the <> stereotype. Figure 5 shows the UML for a sample service that has one operation that takes a sample entity as a parameter and returns a sample entity in response.

Figure 5 Sample Service -- UML Representation This same sample service is represented using the Atlas metadata facility in Figure 6.

Figure 6 Sample Service -- Atlas Metadata Representation Atlas-Java application framework

Any application framework can be used with Atlas. To help jump-start development efforts, the Atlas project provides an application framework based on the Java programming language that can be used as the basis for developing Java applications. This framework is based on the Core J2EE Patterns and provides interfaces and abstract base classes to provide the proper application layering and address the primary application infrastructure concerns of Java applications.

Some examples of architectural mechanisms defined by the Atlas-Java framework include:

• Transfer objects to move entity state across application tiers; • Business objects to encapsulate intrinsic entity business logic; • Data access objects to persist entity state; • Service delegates to provide access to service implementations; • Components to create error and informational messages for service responses; • Factories to create instances of the above classes.

The Atlas-Java framework could actually be used independently of the Atlas MDA capability. To do so, developers would need to manually implement the provided interfaces and extend the abstract base classes.

Atlas-Java differs from other open source frameworks in that it provides a series of architectural mechanisms and the usage patterns for how they all relate to each other. By comparison, the Spring Framework certainly allows the developer to provide interfaces and implementations for the same mechanisms and then use inversion of control

(IoC) to inject the right implementations at runtime based on whatever usage patterns the developer establishes. The value proposition of these two approaches is different in that Atlas-Java provides the mechanisms and their usage patterns out of the box, while the Spring developer must still implement the mechanisms and determine how they are combined together to form usage patterns, which can then be leveraged to implement the business functions of an application.

Atlas-Java is a higher-order application framework that provides a higher level of abstraction, which allows the developer to focus on business logic almost immediately. Existing application frameworks like Spring and others may be used as the implementation technology for Atlas-Java plug-ins that perform specialized "plumbing" functions. Atlas-Java application framework plug-ins

In some cases, the application framework may only provide the interfaces for a particular architectural mechanism. In these cases, specific implementations may be specified by an application framework plug-in. Plug-ins may be based on open source, third-party, or proprietary technologies.

Examples of application framework plug-ins for Atlas-Java include:

• Atlas-Hibernate, which provides an abstract base implementation of the Atlas-Java data access object interface; • Atlas-Struts, which provides abstract base implementations for user input forms based on defined entities; • Atlas-EJB provides base classes for making services remote-able as EJBs as well as the client-side service delegates that can access the services.

There is already a large number of Atlas-Java framework plug-ins developed for the Atlas project. New ones can be easily developed and added to the project as the need arises. Atlas model transformations

Once a framework and associated plug-ins have been developed, model transformations must be developed to generate application code that leverages those assets. A model transformation is focused on creating source code based on application metadata elements that extend classes in either the framework or a plug-in.

There will be one transformation for each kind of PSM-based implementation component. A framework or plug-in may specify any number of implementation components.

The set of transformations that will be applied to the PIM to generate the platform-specific implementation is called the application profile. The profile is defined in terms of one application framework and a set of plug-ins.

Transformations themselves are implemented as templates using the Apache Velocity16 open source template engine. The Atlas transformation engine works by iterating over the set of templates associated with the application profile and applying those templates to the appropriate model elements from the PIM. For example, the transfer object, business object, and data access object templates may be applied to each entity in the PIM. Similarly, the service implementation and service delegate templates may be applied to each service defined in the PIM.

Figure 7 shows a Velocity template that is used to generate the getters for all the fields defined on an entity.

Figure 7 Sample Velocity Model Transformation Template

Source code generated from a transformation may be designated as modifiable or not. Modifiable code will only be generated once, and it is the developer's responsibility to maintain from then on. This is how developer modifications are preserved across builds. Modifiable code is also known as skeleton code. Non-modifiable code is regener- ated each time a build is run.

Figure 8 depicts some of the platform-specific classes that are generated for the sample entity defined in Figure 3 based on a profile that includes the Atlas-Java application framework and the Atlas-Hibernate plug-in. Note that the generated classes extend or implement the classes and interfaces from the framework and plug-in. Also note that the modifiable business object representation is a concrete class that extends a non-modifiable generated abstract class and overrides a protected abstract method defined in the non-modifiable base class. This has proven to be a good pattern for allowing application developers to be creative in implementing business logic without allowing them to violate the architectural patterns defined in the framework.

Figure 8 Sample Atlas-Java Platform-Specific Model

Atlas build lifecycle

Building an application in Atlas always starts with re-generation of the non-modifiable code, generation of modifiable skeleton code for any new PIM elements. From there, the generated code is built along with any modified skeletons. Lastly, any defined unit tests are executed.

The key point is that the model is central to the entire process. Everything related to developing and building an application starts with the PIM. The open source community

Open source software is "software whose source code is published and made available to the public, enabling anyone to copy, modify and redistribute the source code without paying royalties or fees."17

By using open source software organizations can free themselves from vendor lock-in, and lower the cost of entry for other organizations to come in and modify an application using their specialized knowledge or expertise.

These specific benefits have been realized by numerous organizations around the world that have joined in the Linux open source offering which is sponsored, among others, by IBM.18 Like IBM, Number Six is a strong proponent of the use of open source software and adherence to open standards. Our own open source offering, Atlas, is an example of our commitment and thought leadership in this arena.

Advantages of open source

The advantages of open source software extend well beyond the immediately obvious ones such as low cost of entry and avoidance of vendor lock in. It is these other issues that drove, at least in part, Number Six's decision not only to create an open source offering, but also to incorporate existing open source software into it.

Because the underlying source code is available to anyone who uses an open source application, frequently used applications are frequently modified. This has the positive effect of increasing the overall functionality and of stabilizing the reliability of the application over time. Of course, a sound configuration management plan must be implemented to ensure that these frequent changes are introduced in a deliberate and controlled fashion. This constant evolution and improvement becomes especially important as organizations include these applications into their critical business processes.

The Atlas product was developed to intentionally heavily leverage existing open source components to further elabo- rate its functionality. The Atlas development team assembles the Atlas product from existing open source assets rather than having to build it from the ground up. This allows modifications to Atlas to be introduced relatively quickly as needs emerge. Additionally, the inherent stability of Atlas increases as the open source assets it is assembled from evolve independently.

Atlas may be extended to provide alternate implementations of architectural mechanisms (such as persistence or security) that extend the base Atlas framework. These extensions are implemented as Atlas plug-ins. Existing open source assets can be assembled into Atlas plug-ins on top of which application code can be generated. This approach, using open source software, is far more cost effective and flexible than creating (and testing and debug- ging) these plug-ins from scratch. In this way, application development can be jump started and work on implementing the business logic maintains its place as the primary focus of the development team.

Occasionally plug-ins must be created from scratch because no one in the open source community has needed to create on prior. In this case Number Six (or some other contributing organization that has the same need) can create these components and return them back to the community. In this way the environment becomes more robust and useful for all users.

Open source AMDD

Atlas was donated to the open source community through Tigris.org which is "a mid-sized open source community focused on building better tools for collaborative software development".19

In the previous section we discussed how the Atlas software itself is built using other open source technologies. Many of these technologies are, no doubt, well known to the readers of this article.

The Atlas model transformation engine was developed using popular open source technologies. Examples include: Maven20, Ant21, Velocity, Digester22 and others from the Apache Jakarta Commons23 project.

The Atlas-Java application framework was developed using open source as well, but it is mostly built using Plain Old Java Objects (POJO; i.e. not special objects such as an Enterprise JavaBeans). Lightweight technologies such as Apache Commons were used extensively in Atlas-Java.

The Atlas-Java framework plug-ins may also be based on open source implementations such as. Some examples include: Hibernate, Apache Beehive, and Struts.

While the core components are implemented using open source technologies, the reality is that most organizations have made significant investments in enterprise computing technologies. As such plug-ins can also support commercial implementations such as IBM WebSphere, BEA WebLogic, and Oracle TopLink. Case study

In this section we describe a brief case study where Number Six successfully used Industry Standard Best Practices embodied in the Rational Unified Process in conjunction with the Atlas product. The client was a major health services organization that across the US provides health care and other benefits through their system of hospitals and clinics. The product is an online health services portal that is easily accessible to patients and beneficiaries. Our client desired to create a portal through which all patients could access their medical records and other health related services. Of critical importance to the organization was the ability to add new business functions rapidly in response to requests from the user community. Related objectives were re-use maximization, efficiency of the development effort, and the quality and resiliency of the resulting product.

Program objectives

Some of the specific objectives for our client at the start of the project are described here.

Our client desired a wide range of build and deployment options. This was necessary in order to adapt to changing demands placed on the application by the end users. The technique we employed was to split the overall problem domain into more manageable applications, each of which has its own PIM.

Another objective was to achieve loose coupling among components. This was important in order to avoid brittle and sensitive to any changes within itself which leads to improved maintainability.

At an architectural level, they desired clean application layering in order to improve modifiability and maintainability. The goal was to have a proper separation of concerns for each layer of the application -- i.e., the business logic remains in the implementation layer, the UI in the user interface layer, etc. These architectural goals were intended to make the application logic easy to understand and modify.

These goals, when taken together, were intended to make it easy to adapt to changing customer needs. At the same time, the timeframe in which these changes needed to be made was short, with a trend of becoming shorter

32 © 2007 Jupitermedia Corp. Choosing the Right Architecture: What It Means for You and Your Business and shorter over time. The clockspeed requirement for this organization was accelerating at the same time as the ability of the organization to respond was decelerating.

The Number Six solution

The Number Six approach was first grounded in industry standard software engineering best practices as described by the Rational Unified Process. We see this as essential for the success of any development effort.

However, as described in the introduction, even the RUP approach was not enough to ensure customer success given the timeframe that was available. Number Six was sensitive to the fact that organizational viability was at stake, so a new approach built on industry standard best practices coupled with innovative development techniques needed to be applied.

We chose to avoid a "hero" mode to solving the problem -- that is, to simply work excessive hours to meet the deadlines. We knew that would not allow us to address all of the concerns in the timeframe. Instead, we crafted a long term vision for our client's success. The long term vision included implementing the new system using RUP in conjunction with AMDD. This required an investment in an application framework and a model transformation engine in the Elaboration phase. In the Construction phase, the development team was then enabled to stay focused implementing the business logic.

Number Six decided that the automated creation of the software must be done in a way that would enable other vendors, at some future point in time, to be able to make modifications and add functionality to the application as well. This meant that the resulting automation mechanisms must conform to open standards, and indeed, be open source itself. This was the genesis of Atlas.

The resulting Atlas framework and transformations enabled the development team to "take the human out of the loop" in as many cases as possible. Humans make mistakes and by minimizing human involvement in the coding process you remove mistakes before they are made. Moreover, automating the creation of the underlying framework for the application using Atlas had the real benefit of allowing the team to stay focused on the business logic and not the application infrastructure or "plumbing", which enabled the development team to deliver a solution in the allotted timeframe.

Results and observations

The results of this effort were nothing short of spectacular. Seventy percent of all the application code in the application was generated by Atlas (as opposed to being manually developed). By inference based on the argument pre- sented above, one can assume that a large number of the possible programming errors were never made, resulting in tremendous gains in quality.

The client organization had estimated that the changes they needed to make to their application represented a three year effort. Number Six was able to accomplish this result in six months using a team a quarter of the size of the originally slated team. Time compression in the Elaboration and Construction phases of RUP was where the team observed the greatest time savings. By the end of the Elaboration phase, Atlas vastly improved the team's ability to generate the first instances of a truly executable architecture.

Although statistics regarding how resilient the application is to future change, maintainability and others are harder to quantify, there is no question about how dramatic the improvement in these areas has been.

The bottom line is that in a very short time frame, the healthcare portal application was developed, deployed, and is now in use by beneficiaries across the US. Using Atlas, which embodies the AMDD techniques described here, this application is built in such a way that it addresses the other goals identified in the problem statement above.

Conclusion

The ever increasing clockspeed for software development, coupled with the ever shifting foundation on which software is built, do indeed stress the limits of what can be accomplished by most of today's software development organizations. One approach to addressing these two issues is to use Architected Model-Driven Development techniques.

The use of AMDD has demonstrated its value in a real world context for this paradigm shift. In a very compressed timeframe the use of AMDD resulted in an application which was well architected, resilient to future change, and of high quality. The use of Atlas and RUP enabled our client to increase their clockspeed sufficiently not only to remain viable as an organization, but also to be able to provide a portal of world class capability to its patients. Moreover, the use of open source components in the solution achieved the additional objectives of flexibility, maintainability, and avoidance of vendor lock-in. Notes

1 Michael J. Mauboussin, More Than You Know: Finding Financial Wisdom in Unconventional Places. New York: Columbia University Press, 2006.

2 2005 Gartner Application Development Summit

3 Alan Brown, "An introduction to Model Driven Architecture -- Part I: MDA and today's systems," in The Rational Edge, Feb. 2004

4 http://www.omg.org/mda/

5 Core J2EE Patterns: Best Practices and Design Strategies, Alur, et.al.

6 http://springframework.org/

7 http://hibernate.org/

8 http://struts.apache.org/

9 http://ws.apache.org/axis/

10 http://www.omg.org/mof/

11 http://www.uml.org/

12 http://www.borland.com/us/products/together/index.html

13 http://andromda.org/

14 http://galaxy.andromda.org/docs/andromda-documentation/andromda-getting-started-java/java/create-value-object.html

15 http://www.compuware.com/products/optimalj/default.htm

16 http://velocity.apache.org/

17 Douglas Heintzman, "An introduction to open computing, open standards, and open source," in The Rational Edge, July 2003.

18 Daren Hanson, "The evolving ecosystem of open source and open computing," in The Rational Edge, July 2005.

19 Tigris.org website

20 http://maven.apache.org/

21 http://ant.apache.org/

22 http://jakarta.apache.org/commons/digester/

23 http://jakarta.apache.org/commons/index.html About the authors

Steve Andrews has over 12 years of experience designing and developing enterprise-class software solutions for customers across a variety of industries and government agencies. He is currently focused on using model-driven architecture (MDA) techniques to develop service-oriented architecture (SOA) based business applications. Throughout his career, he has designed and implemented innovative solutions to bridge the gap between business and the enabling technology concerns for his clients. Along the way, he has found ways to bring those approaches to bear in the larger organizations that he works for where they can be leveraged across business domains. Now he is using open source to share these techniques across the software industry as the founder and owner of the Atlas project in the Tigris open source community. He can be reached at [email protected].

Stosh Misiaszek is the Director of Strategic Alliances for Number Six Software. After beginning his career as an assembly language programmer twenty years ago, he spent time developing methodology and delivering training for large corporations. He currently manages strategic alliances for Number Six software, a position which allows him to work with other solution providers in the industry to build partnerships that offer unique business value for his clients. He holds an MS in computer engineering from Syracuse University. He can be reached at [email protected].

Choosing the Right Architecture: What It Means for You and Your Business

Enterprise Application IBM Resources • Introduction to the IBM Asset Transformation Transformation: Leveraging Your Workbench • Faster Application Change and Reuse with Investment in Proven, Mission- WebSphere Studio Asset Analyzer • WebSphere Host Access Transformation Services critical Business Applications Toolkit V7.0 • Create a Java Web Application without Level: Introductory Knowing Java • IBM WebSphere Application Transformation Demos: Georgiann Zaglakas, Reporter, The Rational Edge WebSphere Developer for zSeries (WDz) • Accelerate Integration of Mainframe Applications into the Web World First published by IBM at http://www.ibm.com/developerworks/rational/library/dec06/zaglakas/index.html All rights retained by IBM and the author.

15 Dec 2006 from The Rational Edge: This article describes how the new Enterprise Generation Language technology supports the development of service-oriented architectures by leveraging existing IT resources and legacy language development teams.

Most of today's enterprises run on complex, legacy applications that are critical to supporting business operations. Unfortunately, many of these heritage applications come with a high price tag -- they are costly to maintain, and the lack of skilled IT personnel to support them can create a significant burden to an already stretched IT organization with a limited budget and human resources.

For many businesses, Enterprise Application Transformation is quickly becoming the solution to their business problem of what to do with their aging legacy applications. Essentially, IBM's Enterprise Application Transformation strategy offers businesses the tools and best practices that enable them to analyze, transform, and deploy systems that leverage a heritage computing environment. Focused on the reuse of current applications, Enterprise Application Transformation enables businesses to quickly and cost effectively migrate their current, proven legacy applications into more flexible systems that support new middleware and emerging application architectures. Running a business on legacy applications

Today's IT environment plays host to a range of monolithic, entrenched legacy applications that run an enterprise's core operations and drive business growth. Created years -- if not decades ago -- these applications were often- times customized by an IT staff trained in older 3GL and 4GL languages. Despite their age, these systems delivered the functionality, capabilities, and performance that helped many enterprises maintain a competitive edge in the marketplace.

Unfortunately, many of these heritage applications have become a burden to the IT organizations that support them due to the enormous costs of maintaining and updating these applications, not to mention the exorbitant maintenance fees that are paid to some of the independent software vendors. In addition, many of the older 4GLs have not been enhanced significantly in years, so enterprises are unable to exploit the many advances in modern architectures and middleware, thus putting them at a competitive disadvantage. For example, most companies are interested in moving towards a service-oriented architecture (SOA), but this can be quite challenging when systems are implemented in older technologies.

With the advent of newer middleware and application architectures, enterprises know that staying with their legacy applications as is -- even though these systems are not broken -- is not a long-term answer. However, preserving the competitive advantage they've achieved through the use of these applications and the customization that they contain still remains paramount. Enter Enterprise Application Transformation -- a systematic and comprehensive approach to reusing software assets in a way that allows businesses to maintain their competitive advantage while enabling them to support newer business models such as SOA.

"Enterprise Application Transformation is taking center stage because it enables enterprises to leverage their investments in proven IT assets and better utilize the skills of their IT professionals," explained Ed Gondek, business unit manager, Enterprise Application Transformation and Enterprise Modernization, for the IBM Rational brand. "Companies have invested a lot of money and time creating applications to run their core business operations, so it's understandable that they don't want to throw that all away -- nor should they. With Enterprise Application Transformation, companies can take the core logic that was built into their original applications and bring it forward into a new environment that provides more flexibility, is more cost effective, and allows them to preserve the levels of productivity and simplicity they are accustomed to."

The new generation of IT systems requires software development capabilities that support new middleware and emerging application architectures. Flexibility is the name of the game, but due to the variety and complexity of activities and artifacts necessary to implement these solutions, it is essential that development organizations utilize proven methodologies, processes, and tools during software development. This equally applies to Enterprise Application Transformation. Is it time to transform?

Transform or not to transform? That really is the question. And for many enterprises, the answer is pretty clear: The pressure to change is coming from everywhere. Management knows they must modify their IT systems to increase agility in a world of intense competitive pressures and shifting customer needs. IT organizations know that maintaining the status quo is unacceptable in an IT environment that is quickly evolving due to the development of newer systems, interfaces, and architectures. And end users know that mounting marketplace pressures means they must be able to access data, make business decisions, and perform their jobs more effectively and be overall more productive.

Yet frequently, enterprises delay embarking on an Enterprise Application Transformation initiative. For many, the transformation process itself seems like an unnecessary step when a business is thriving -- and may even be seen as downright dangerous to their business operations. For example:

• Many legacy applications are "off limits" to developers due to the critical nature of the business operations they support. Therefore companies may choose to stay where they are rather than risk damaging their operations and spending time and money on a project when "more strategic" initiatives are underway. • Companies have made huge investments in time and money developing their heritage applications, many of which have hundreds of thousands (if not millions) of lines of code that have to be recoded. Adding to their concerns is the fact that migrating these applications is seen as a timely and costly undertaking. • Since the current applications are "running just fine," companies don't want to disrupt the stability of their operations. For many a "if it ain't broke, don't fix it" mentality ensues, with little thought to what the next five to ten years will bring in terms of new technologies or additional costs to maintain these aging applications.

According to Gondek, one of the key reasons for delay is the fear of the unknown: "When we talk to companies, we often find that they know they have to transform their IT operations, they just don't know how to go about it. For many it's the uncertainty of how to make those changes, what impact those changes will have on their business, and most importantly, where to begin the process. At IBM, we help businesses understand all aspects of transformation, show them how to mitigate their risks, and work with them throughout the entire migration process.

Ultimately, the biggest risk isn't 'taking the first step' but failing to take any steps at all." Choosing the solution that is right for the business

For enterprises that do decide to modernize their business-critical applications, several options are available. In fact, there are three main strategies that enterprises can use: complete rewrite, replace, and transform.

With "rip" and rewrite, enterprises completely tear out their legacy applications and rewrite them using newer technologies. With a replace strategy, enterprises purchase off-the-shelf applications and customize them to meet their business needs. Unfortunately both of these methods can be extremely costly and time consuming, resulting in millions of dollars and several years at best spent coding and recoding, customizing, and testing these new applications to gain the same functionality, performance, and stability as their legacy systems provide. And that doesn't even cover the resources required to retrain the IT staff and end users of the applications.

Enterprise Application Transformation enables companies to reach their goals in a faster, more cost-effective, and more productive way. Built on a three-phased approach, Enterprise Application Transformation enables companies to modernize their business-critical applications in a way that reduces development and maintenance costs, improves the application interface, allows existing development teams to move to new technologies with negligible learning curves, increases developer productivity, and makes their applications SOA-ready. A key technology that enables this is IBM Rational Enterprise Generation Language (EGL). Building solutions with EGL

EGL is a core component of IBM Rational organization's comprehensive Application Governance and Lifecycle Management solutions. A highly productive, flexible business language that offers a development model familiar to business application developers, EGL allows developers to quickly build modern business services without having to learn and master Java/J2EE, Web technologies, or Web Services Description Language/XML Schema Definition (WSDL/XSD) -- thus eliminating the need to re-staff or do extensive re-training in order to create the next generation of IT systems.

Businesses know how crucial their investments in existing legacy systems are, and Enterprise Application Transformation tools help them migrate business-critical applications to EGL to fully leverage their business value. Through code migrations of VisualAge Generator, Cross System Product, Informix 4GL, Natural, CA Cool:Gen, CA Cool:Enterprise, CA Ideal, CA Synon, CA Telon, Maestro, Seer/HPS, RPG, COBOL, and other 3GL and 4GL applications, IT can leverage existing investments in proven, reliable, production-ready code by preserving this logic while moving rapidly onto a modern software development platform. Highly automated conversion utilities enable IT to migrate to EGL in a cost-effective, efficient manner, which greatly reduces risk and shortens the migration process.

"The beauty of EGL is in its ability to provide maximum flexibility by supporting many styles of programming, including services for SOA, Web, green-screen, batch, and soon Rich Client Applications (using the Eclipse Rich Client Platform, or RCP), across the broadest variety of platforms, including WebSphere, System i, System z (CICS, IMS, and batch), Linux, UNIX, and Windows," said Hayden Lindsey, IBM Distinguished Engineer and Director, System z and System i Tools, IBM Rational software. "For example, since most online legacy applications provide green- screen interfaces, during the migration process, new Web user interfaces can be provided. Or if the objective is to repurpose stable application functions for SOA, then application transformation to EGL sets the foundation for this activity."

EGL plays a critical role in mitigating the risks of Enterprise Application Transformation. EGL and its open standard, Eclipse-based software development platform can future-proof IT application organizations from the ever changing world of middleware, databases, languages, platforms, and computing environments. Moving through the transformation process

The IBM Rational Enterprise Application Transformation process is a standards-based strategy that entails three key steps: 1) DNA (discovery aNd analysis), 2) transformation and knowledge transfer, and 3) implementation and deployment. It encompasses a host of IBM and business partner provided services, IBM and third-party transformation tools, and IBM software. Within each phase, the IBM Rational team and the enterprise's business and IT managers work closely to set and measure the goals and objectives of the project to ensure success.

Discovery aNd analysis (DNA). This initial phase is undertaken to assess and inventory an enterprise's current legacy application environment, including application source code, database management systems, operating systems, and platforms. As part of this process, an analysis is completed of all the system elements, so there is a clear understanding of what is used and not used, including backup, archive, integration, and replication utilities; all pur- chased software; and any inter-relationships or inter-dependencies between these elements. A full inventory and assessment of the source code is also made, identifying the style of coding, verb usage, screen I/O, broken links, data areas, and many other source code attributes, as well as unused code or underutilized code that may or may not be migrated during the transformation process.

Often, this analysis is completed off-site using an analysis engine housed on secure servers to reduce the costs associated with purchasing and installing the analysis software and running the code through an iterative analysis process. At the end of this phase, which takes only a few weeks, a detailed analysis report is created that provides an "eyes wide open" view into the enterprise's IT environment that is used to size and scope the rest of the transformation process.

Transformation and knowledge transfer. During this second phase, an automated application conversion takes place on the customer's software and database application using source code and data structures provided by the customer, as well as a small amount of test data. This conversion process, performed using transformation software on an off-site, secure server, is completed with a 95+ percent automated conversion rate, which reduces the costs and time associated with any migration. This iterative process enables the original application source code to be run and rerun to ensure a high-quality transformation. During this process, the source code is converted to EGL.

This second phase also includes a knowledge transfer process that ensures that the customer's development team is comfortable with the new software development environment. A proof-of-concept (PoC) and onsite educational sessions are conducted to train application developers on the tools they will use in the future, including EGL and IBM Rational Application Developer software.

Implementation and deployment. This final phase of the transformation process focuses on extensive testing of the applications with real data. A range of tests, including full unit and systems testing, user acceptance testing, and load/stress testing, take place at the customer site. Also during this phase, if the migration is from a ADABAS/Natural system, a new database management system is created, the new database management system tables are loaded, and data conversion and migration is completed. Finally, the application is deployed to the production environment as part of the customer's standard change management processes.

The entire transformation process is completed with the deployment of a modern software development environment. "These tools and best practices enable companies to manage their system requirements, better manage change, test their applications, improve application development and modeling, and better maintain their source code versioning via a secure repository. The IBM Rational organization provides a complete Governance and Lifecycle Management solution," stated Gondek. Gaining the benefits of modernization

Ultimately the proof of success is in the long-term benefits that can be achieved from a transformation process. For companies that have undertaken these types of projects, results have included:

• Reducing the time and cost of maintaining applications significantly by eliminating older technologies and platforms • Lowering the risks based on the reuse of proven, tested functionality migrated from existing core business systems • Redeploying stable functionality to SOA, model-driven, or other new architectures, including Web services, Java/J2EE, and Web/Rich client • Leveraging their existing development staffs without expensive retraining in languages such as Java/J2EE or other OO programming paradigms • Moving to a cost-effective, cross-platform application development strategy • Breaking down the silos within the development team by enabling developers to work on any project regardless of the target platform

"Companies know that to address competitive pressures and market conditions, they must modernize their aging applications to support new and emerging application architectures and technologies," concluded Lindsey. "Enterprise Application Transformation enables companies to reuse their current business-critical applications in a way that pre- serves their investments and maintains the full functionality of their systems. Most importantly, it enables companies to modernize in a cost-effective and timely manner with limited risks and maximum return on investment." Resources

• For more information, contact Ed Gondek at [email protected]. • For more information on IBM's Enterprise Generation Language (EGL) and how it used as part of the Enterprise Application Transformation process, access the following: • EGL kit • EGL family Website • EGL Zone on developerWorks • DataSheet: IBM Rational Enterprise Generation Language • White paper: "Exploiting Enterprise Generation Language for Business Oriented Developers" • White paper: "SOA Made Simple with EGL" • Redbook: Rational Application Developer V6 Programming Guide • Redbook: "Transitioning: Informix 4GL to Enterprise Generation Language (EGL)" • EGL forum About the author

Georgiann Zaglakas is a freelance writer who specializes in translating complex technical and business information into clear, concise communications materials. During her twenty-year career, she has worked extensively with clients in the high-tech industry, developing internal and external communications. She currently writes whitepapers, articles, testimonials, product and marketing collateral, and Web-based communications.