Level: Intermediate Kris D. Hansen (kris.hansen@mac.com), Solutions Architect, Author
26 Jun 2007 Architecting an application requires an understanding of the environment
that the application will be deployed in. You must make assumptions about who will
use the application and how they will use it. For environments with factors that create uncertainty and a potential for change, this article discusses approaches and tools that can help reduce the impact of volatility on your application.
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.
Figure 1. Forces of change and architectural tools and methods that can mitigate them
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.
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).
Figure 2. IBM Rational Modeler 7 performing refactoring of a model
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.
Figure 3. Browsing the ontology of pizza
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.
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.
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
Get products and technologies
Discuss
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 page
| 
