Part of the role of the architect is to be able to predict the future. This can be difficult, but it is an important aspect of designing the right solution for the given requirements. Anticipating the future is easier if all current and future requirements are clearly and succinctly stated, but this is rarely the case. You need to gain an understanding of the big picture, both today and in the future, and then use your experience and judgment to identify the optimal solution.

This kind of foresight might be less important for smaller, lower investment applications. In these cases, the amount of investment is minimal, and discarding the application entirely is of little consequence. In cases where a large strategic business application is being developed, considering future conditions is critical. Investing a significant amount of money into an application that becomes irrelevant within a few months or years due to changes in the business environment is not a good thing and in many cases can be avoided.

In cases where a large investment is being made, you need to have a clear understanding of the underlying business strategy and environment to determine the amount of potential volatility and the appropriate design to mitigate the risks associated with large-scale change.

Skills and competencies

Much of the research around effective software development emphasizes the importance of understanding the requirements. Most architects agree that this is essential to the success of the project. However, in scenarios where requirements can change dramatically, additional investment in understanding the potential sources and areas of change and designing for change can make the difference between an application that is difficult to change and one that is ready for change.

A volatile environment differs from a stable environment in that changes can be profound and abrupt. In most environments, moderate change is expected and usage patterns, resource requirements, and integration requirements can be anticipated. In scenarios where projections cannot be reasonably made and there are many unknowns, you can design and position the application for the unexpected.

There are many sources of volatility, and rapid change often comes in an unexpected form. Some of the examples of significant change to consider when designing an application are discussed in this section.

Industry forces

Organizations exist within an industry context. If this environment changes, the impact on the organization can be significant. Questions that you can ask in this area include:

• What are the macro trends in this industry that should be considered during application design?
• What are my organization’s strategic relationships, and how could these change?
• What is the strategy of the organization, and how does the application support this?

Industries generally follow patterns associated with growth or consolidation and change as they mature. If many firms in your industry have recently joined forces, it might be worth considering whether this is a possibility for your firm. If the industry is less mature and highly dynamic, the chances of industry-wide changes are higher.

Anticipated growth or attrition

If your organization is experiencing rapid growth, plan for growth. This sounds like a basic point, but nonfunctional requirements are sometimes considered static. In high-growth environments, an application sized at the project’s inception could require resizing at the time of implementation. For growth, it is important to understand the rate of growth and project usage and peak requirements based on that rate of growth. For nonfunctional requirements in a high-growth environment, estimates should be especially conservative. Attrition is another scenario to consider. If there are lines of business or categories of products that are in decline, consider this during the design of the application. It is important for the business to understand the cost/benefit relationship associated with building system functionality for a declining unit or product line because this area will experience decreasing benefit over time.

Success

Success can push the limits of a system, and systems are often designed to conservative projections. Having a plan for success and a means to respond to wildly successful adoption is an important consideration when designing an application. This is especially true of public-facing, Internet-based applications. For internal applications, adoption can spread as the business value of the system gains awareness within the organization. This often elicits new requirements as new groups of users are accessing the system, and having a means of capturing and managing these requirements can extend the application’s longevity.

Mergers and acquisitions

If your organization has a strategy of achieving growth through acquisitions, consider how newly acquired entities will fit within your design. Having a well-thought-out data model, for example, makes it easier to migrate a variety of data sources into your application. In an environment where mergers and acquisitions are a reality, having an adaptable application also includes considering potential integration scenarios. New acquisitions are often run as separate business units but integrated on the back end for enterprise reporting and other purposes.

Back to top

Tools and techniques

Application flexibility is the means of reducing the risk of change. If you identify the potential for volatility in your application’s future, there are several approaches you can use to establish application flexibility.

It is important to note that flexibility often comes at a cost. You need to weigh the benefit associated with the increased complexity or effort compared with the cost of adding this element into the design. It is also important to consider the required application lifespan. If this application is expected to exist for only a few months or years, you may want to reconsider investments into additional flexibility components.

Model-driven architecture

Designing an application based on a full model of the system can make it easier to understand and implement change. The model can include dependencies and interrelationships that allow you to understand the impact of decisions during the refactoring. There are several approaches to model-driven architecture (MDA), including approaches where some or all of the code is generated from the model and scenarios where the model is used as a guideline for development. Unified Modeling Language (UML) is a standard method of describing an application and is an integral part of the MDA approach to development.

Some have predicted the death of MDA due to Service-Oriented Architecture (SOA). It is important to differentiate between the pragmatic application of MDA principles and the full theoretic vision of MDA. SOA has changed the way that organizations think about developing applications, which has challenged the full MDA vision, but modeling and driving application architecture from a model is an effective way to develop an application that is ready for change.

IBM® Rational® Software Architect V7 is an example of an Eclipse-based tool that bridges the world of modeling with the world of developing. Rational Software Architect is a combination of IBM Rational Application Developer and IBM Rational Software Modeler. Rational Software Modeler has the ability to easily refactor models and then export them as either UML or Extensible Markup Language (XML) Metadata Interchange (XMI).

Business process management

Externalizing the management of the business processes associated with your application can significantly reduce the amount of effort associated with process changes. With this design element, workflow routes and processes are managed outside of your application within a business process management (BPM) tool. BPM tools normally facilitate the design, execution, and management of processes. With this design component, workflow changes (for example, adding a second approver for a transaction) are easily done and don’t affect the code itself. Applications for organizations that must adhere to shifting regulatory requirements are especially suited to using BPM tools.

Business rules engines

Externalizing the business rules from the code and making them user accessible is an effective means of building an application that is anticipating the future. There are several organizations that offer rules engines and a Java™ Specification Request (JSR-94) that has defined the interface to third-party rules engines.

By implementing a rules engine, changes to business rules can be managed and implemented by business analysts, thereby avoiding programming for changes to business logic.

Ontology modeling

An ontology is a description of entities and the relationships between these entities. Ontologies are used to express complex domain areas as models, and they are shared to increase the consistency and collective knowledge around domain areas. Using an ontology editor, you can visually model, define, and express entity relationships and then export the ontology as XML or Resource Description Framework (RDF) for use in your application. In the event of a significant refactoring of entity relationships, these can be modeled visually, verified, and then imported into your application, ideally avoiding any programming changes.

Parameterization

Building parameters into your application where change may occur is a way to avoid redeveloping parts of your application. Where feasible, consider not having any settings or values coded into the application and, instead, place them in a database as parameters that are accessible through a restricted admin user interface.

Publish and subscribe

Having your application publish events into a service bus and subscribe to other events is a method of loosely coupling your application for application integration activities. Instead of using a point-to-point Java Message Service (JMS) connection, consider using a subscription. This way some abstraction of the source is provided and integration is more manageable if the number of integration points increases in the future.

Enterprise Service Bus

Similar to the abstraction provided in the publish and subscribe pattern described earlier, an Enterprise Service Bus (ESB) also abstracts endpoints and reduces the complexity of managing interdependencies. An ESB goes further by providing multiprotocol facilities and SOA standards. A repository or directory service is often included in an ESB product, facilitating the move toward an SOA-based integration approach.

Most ESB products also include traditional enterprise application integration (EAI) advantages such as application adapters and support for message transformation and enrichment. Including an ESB in your integration strategy can ease the effort of integrating with new and unknown business partners in the future.

Service-Oriented Architecture

Using SOA as a method of increasing flexibility probably deserves an article in itself. Many of the other approaches discussed thus far work in conjunction with an SOA approach to integration and application design.

SOA has evolved into a multilayered discussion. It is a business strategy or a new way of thinking, but it is also a method of designing and integrating applications. The spirit of SOA lies in loosely coupling course-grained services that solve real business problems.

Defining your application as a collection of business services aids reuse and reduces the impact of the change associated with adding new business services. New discipline and governance is required in managing the dependencies associated with service reuse, and you need to consider this when moving toward an SOA approach to development and integration.

Back to top

Milestones

There are two aspects of architecting applications for volatile environments: design and post-implementation considerations. During the design phase, architectural methods and components are selected in areas where change is expected and flexibility is required in the functional requirements. For post-implementation considerations, the application is designed to be responsive to changes in the nonfunctional requirements.

After your application goes live, the assumptions associated with nonfunctional requirements are tested. In a high-growth or volatile environment, estimates associated with load and performance are often difficult to formulate. In this context, planning for scalability is vital.

In a dynamic environment, application performance and utilization is a moving target. An application that performed well last week could be flooded with requests this week.

There are many ways to expand the capacity and improve the performance of an application. Considering this during the design and implementation phase will reduce the effort and confusion often associated with unplanned utilization.

Vertical scaling

Being able to scale up vertically involves deploying your application on a platform where the computing capacity can be increased with minimal disruption to the deployment. These days, highly scalable hardware exists that can increase the processing, memory, and disk capacity seamlessly and often without any application disruption. The more advanced IBM System i™ (iSeries®) IBM System p™ (pSeries®), IBM System x™ (xSeries®), IBM BladeCenter®, and IBM System z™ (zSeries®) servers are all capable of this. Some of the higher-end servers allow for the incremental purchase of processors that can be purchased and enabled as processing requirements increase.

Horizontal scaling

To increase your application performance horizontally, your design needs to be able to accommodate additional servers that can participate in the workload. This can be achieved through application design, server clustering, load balancing, replication, or a combination of all of these elements. If an application is completely stateless, it is designed such that session state is not maintained at the application server or data tier, and every connection is essentially a new connection without any history or context for the session. Developers reading this might cringe. Additionally, statelessness can be difficult to achieve and can lead to multiple round trips to the database for information that is normally stored within the context of the session. However, the advantage of designing a stateless application is that horizontal scaling is easily achieved. Adding Web servers, application servers, and database servers and load balancing across them becomes straightforward. If additional load is expected, adding servers increases the system capacity. Stateful applications can scale horizontally as well, and this generally involves replicating session state across the application server cluster (which is a feature of most enterprise-grade application servers, including IBM WebSphere® Application Server). The benefits of scaling stateful application are less impressive due to increased complexity and the performance impact associated with replication of state or data. With the additional improvements in availability, horizontal scaling is often worth the effort.

Understanding performance

One of the most important elements of managing an application that exists in a volatile environment is to have a clear understanding of how that application is performing. Performance is a nebulous issue. Simply monitoring central processing unit (CPU) and memory utilization is insufficient. Understanding how the application is performing on each tier and for each class of transaction or where latency exists in the code is crucial.

Performance testing your application is a critical step in the implementation process, especially when expected user behavior is unknown or high peaks are anticipated. The goal in performance testing is to validate that your performance levels on the deployment platform are as expected and also to understand how your application performs in this environment. It is also important to stress test the application and to understand the upper limits of what the application can handle, where performance is bound at these levels, and the symptoms of higher-than-optimal load. Knowing how your application behaves when it is overloaded helps you identify what needs to be addressed from both an application and a hardware environment point of view.

You can do performance monitoring using diagnostic tools that bootstrap the Java Virtual Machine (JVM) and provide a view of the application from the inside out as it executes on the JVM. These tools are able to identify the sources of latency and pinpoint the source of bottlenecks both internally in the application and in the operating environment. You can also run probes in production environments to provide insight into performance, but the level of diagnostics should be limited to prevent impacting the performance.

Creating a scalability plan

If you anticipate that you may need to scale your application up, create a scalability plan in advance. This step can save time determining which options will best increase capacity and improve performance. The plan should identify performance milestones in terms that make sense within your environment (for example, number of users or total daily transactions processed) and correlate these thresholds with the improvements that can be made to increase throughput. There may be points where vertical scaling is no longer feasible or where significant architectural changes may be required. Identify these in the scalability plan so that sufficient time is provided for the measures to be implemented.

Back to top

Summary

Seeing into the future is difficult, but anticipating volatility is possible. It means considering the big picture and testing the boundaries of current assumptions. If uncertainty is expected and the investment is justified, you can make decisions during the design of the application to mitigate the impact of change on the application over time. After you implement an application, you need to understand the scalability options to know which ones to employ and when. This approach can help your design retain its relevance longer and, ultimately, be more cost effective.

Resources

Learn

• Check out the Object Management Group, an industry consortium focused on establishing international modeling standards.
  
  
• "An introduction to Model Driven Architecture" (Alan Brown, developerWorks, February 2004) discusses MDA in theory and practice and includes information on how IBM Rational aligns with MDA.
  
  
• "Getting Started With the Java Rule Engine API (JSR 94): Toward Rule-Based Applications" (Qusay H. Mahmoud, Sun Developer Network, July 2005) provides an overview of the JSR-94 standard and provides code examples of how to integrate your application with a rules engine.
  
  
• "IBM WebSphere Developer Technical Journal: Deploying publish and subscribe applications into the Service Integration Bus" (developerWorks, August 2005) describes how to implement a publish and subscribe framework with the Service Integration Bus included with IBM WebSphere Application Server 6.
  
  
• "Increase flexibility with the Service Integration Maturity Model (SIMM)" (developerWorks, September 2005) discusses a method of assessing SOA maturity and advocates an incremental approach to SOA adoption.
  
  
• In "Architecture for high-volume SOA-based enterprise systems," (developerWorks, March 2006) Mark Davydov discusses methods of improving the scalability and throughput of SOA-based systems.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  
• Use IBM on demand demos to learn about various software products and technologies from IBM.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  

Get products and technologies

• Download a trial version of Rational Software Architect.
  
  
• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational, Tivoli®, and WebSphere.
  
  
• Find more information about the Protégé ontology editor.
  
  

Discuss

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

About the author

Kris Hansen is an enterprise technology architect and author who has been working with IBM technologies for more than 10 years. He has achieved seven IBM certifications, including IBM Certified Solutions Architect, Solutions Designer, and Solutions Technologist. Kris was the VP/CTO of an IBM business partner based in Honolulu, Hawaii, where he led the architecture, estimation, and delivery of many successful projects. Recently, he returned to Canada, where he designs technology solutions for a rapidly expanding regional bank.

Rate this article

Comments

Back to top

Table of contents

• Skills and competencies
• Tools and techniques
• Milestones
• Summary
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

Dig deeper into Rational on developerWorks

Discover knowledge paths

Skill-building guides for Rational, Linux, open source, cloud, Java, business analytics, and more.

Special offers