 | Level: Intermediate Stephen B. Morris (stephenbjm@yahoo.com), CTO, Omey Communications
13 Nov 2007 Organizations today face the challenge of two important
enterprise architecture requirements: the need for agility and the overhead of
regulatory governance. These requirements can be seen as mutually antagonistic
-- if business processes must be flexible, then governance of those processes
may be difficult. This article, part six in a six-part series, explores the notion of using manageability as a
key enterprise architecture (EA) quality attribute to solve this problem. EA
development is an ongoing process, and the central idea of this article is
that by applying manageability as an EA attribute, the organizational
processes, systems, and software become manageable.
Organizations today face the challenge of two important enterprise architecture
requirements: the need for agility and the overhead of regulatory governance. These
requirements can be seen as mutually antagonistic--if business processes must be flexible, then governance of those processes may be difficult. The greater the need for agility, the more difficult governance becomes. The use of manageability as an EA quality attribute can help solve this problem. If the EA supports manageability, then the implemented elements of that EA can be orchestrated. This, in turn, allows for the required levels of business agility and governance. This article explores the notion of manageability as a key EA quality attribute. Two tools are described that support manageability: Apache Geronimo and IBM® WebSphere® Application Server. EA development is an ongoing process, and the central idea of this article is that by applying manageability as an EA attribute, the organizational processes, systems, and software become manageable. This manageability can then be used for a variety of purposes, such as driving the information technology (IT) infrastructure by business needs, providing for agility, and facilitating governance.
Skills and competencies
Earlier articles in this series discuss the growing importance of architecture to the enterprise. The lessons drawn from these articles are that good architecture provides both business value as well as benefits to the IT infrastructure. This is achieved by engineering the EA so it effectively links people, processes, and technology. In this article, I look at the issue of manageability as an architectural quality attribute and how this provides an even greater degree of agility and enhanced EA longevity. However, the notion of manageability is a little abstract -- what does it mean and how about an example?
In one sentence, manageability means being able to view and modify the state of a given system or piece of software. Management actions range in size and scale from rebooting a machine to initiating a massive payroll run. Notice that my two examples are respectively a machine-level interaction and a business-process initiation.
If the associated EA contains manageability as an architectural quality attribute, then actions such as the above are easy to perform, and, more importantly, they can be automated. The associated benefits accrue across the enterprise spectrum.
All actions are management operations
You might think that spinning off a business process is in fact not a management action. Such actions have traditionally been separate and distinct from management operations. It's my opinion that this is a mistake. All interactions with systems and software are conceptually management actions. Opening an e-mail message is a management action initiated by a local user. Backing up a multi-server database is also a management action. Clearly, the latter is an action executed by an IT administrator, but both actions are essentially management operations. The difference between the two is in scope and scale.
Copying a massive file from one user machine to a server can markedly affect the available local bandwidth. So, each user can execute actions that have a substantial effect on the overall managed (that is, the computing and networking) environment. Because such actions can affect the state of the managed environment, they are conceptually (albeit inadvertent) management actions.
Viewing application interactions and IT operations as separate disciplines has tended to produce too many silos (that is, non-overlapping, yet interdependent entities). The result of the silo approach has, for example, made the migration to Service-Oriented Architecture (SOA) far more difficult.
My contention is that most actions should be seen as management operations, and this is easier if the EA includes manageability as one of its architectural quality attributes. One of the merits of such an EA is the ability to maintain order by allowing and disallowing certain actions based on identity, impact, resource use, and so on.
Understanding manageability
An understanding of the concept of manageability can form the basis of the required skills and competencies for EA manageability. Manageable software and systems have the following major characteristics:
- Instrumented for monitoring and control
- Automated operation
- Informative or event driven
- Pattern support
- Model based
These characteristics are examined in the following sections.
Instrumentation
Managers can use the monitoring and control instrumentation to view and optionally modify the state of software and systems. Instrumented software and systems can feature a variety of technologies including:
- Simple command-line interface for script support
- Simple Network Management Protocol (SNMP), Web Services Distributed Management (WSDM), and other standards
- Proprietary technology
Many systems in the telecom and UNIX®/Linux® domains use scripts exclusively for management. Script-based management works well, but this approach suffers from problems of scale and complexity. When the number of managed entities goes beyond a certain threshold (typically around 50 nodes), scripts can become unwieldy. Also, the need for interpretation can result in performance bottlenecks in the use of scripts. Some management systems may even present graphical interfaces while behind the scenes the software employs scripts.
SNMP, WSDM, and similar standards, such as Distributed Management Task Force (DMTF), provide increased levels of abstraction because they are essentially model based. Management data is predefined and extensible, and a simple protocol is provided to allow access to and modification of the data. However, both technologies don't scale well as systems and software grow. Nonetheless, they are better than no management capability.
Proprietary technology includes solutions such as embedded Web servers. While useful for Web application interactions, such proprietary schemes typically have limitations related to performance and scale.
Automated operation
A key aspect of a truly manageable entity is automated operation. Unattended operation and resiliency are viewed as successful endpoints in IBM's autonomic computing initiative. This is because the low-level details -- such as log file inspection and automatic process restarts -- can all be handled by software. By reducing human input, automation becomes possible. So, closed-loop automation is one of the deliverables of an autonomic computing system.
Event-driven management
An informative entity is one that automatically provides directed information on state, loading, failure modes, and so on. In other words, an IT manager is kept up to date on important issues related to the entity without being submerged by data. The normal mechanism for this is events -- messages that a managed entity proactively sends when some important issue occurs. An example of an event is when the loading on a given system exceeds an acceptable threshold. The system identifies that its loading has exceeded the defined threshold and emits an event message. Traditionally, the problem with events is that too many of them are emitted or, worse still, the event mechanism uses up precious computing resources on the managed entity.
Pattern support
Pattern support is most easily described with an example. The Java™ 2 Platform, Micro Edition (J2ME™) platform is designed for use in small resource-constrained devices such as mobile phones, Personal Digital Assistants (PDAs), TV set top boxes, and so on. What is interesting about J2ME is that it supports an application manager that controls the execution of software on the platform by ensuring that only a finite number of well-defined state transitions can occur. This relieves the programmer of a substantial burden, and the only requirement is that the J2ME code be written according to a specific pattern. The Java methods that must be written by the programmer include startApp(), pauseApp(), destroyApp(), and the provision of a constructor. When this pattern is adhered to, the application manager takes care of the execution. Because Java 2 Platform, Standard Edition (J2SE™) and Java 2 Platform, Enterprise Edition (J2EE™) do not tend to run on resource-constrained platforms, they do not feature similar deployment patterns.
Model-based operation
The area of model support for management is fragmented, for example, SNMP, Common Information Model (CIM), Common Management Information Protocol (CMIP), and so on. Each model has advantages and disadvantages. Traditionally, the greatest disadvantage has been that of separation. Management capability is generally implemented as an add-on -- something that gets bolted onto the software towards the end of development or (worse) after a given development is complete.
However, new technologies such as the Eclipse Modeling Framework (EMF) and the more recent Eclipse Graphical Modeling Framework (GMF) may help solve this problem. These tools provide the means to define a model at the same time as major development. In effect, systems and software created using EMF and GMF are model based from the beginning. This is a more natural basis for a manageable EA -- if the components are manageable, then the overall architecture should also be manageable.
The management problem
So, in spite of about thirty years of effort, the problem of managing systems and software remains essentially unsolved. Why is this? The main reasons are:
- The closed nature of proprietary software
- Manageability is not a differentiator
Before the open source trend started, the vast bulk of software was closed to all but developers and designers. By implication, this tended to mean that the management facilities were minimal, basic standards, nonexistent, or proprietary in nature. So, software from vendor X required management tools from vendor X, if indeed such tools existed.
By not viewing manageability as a differentiator, vendors typically missed an opportunity to present their offerings as true end-to-end solutions. Now that EA is an emerging discipline, the whole issue of manageability is resurfacing, though in a new form. EA requirements for SOA now typically include the need for service orientation, loose coupling, easy orchestration, and support for the Enterprise Service Bus (ESB) pattern. This underlines the need for a unified approach to the integration of infrastructure elements such as servers, applications, data sources, services, and so on. This approach must be message oriented, event driven, and service oriented.
The increased emphasis on EA today provides an interesting backdrop for revising the need for manageability as an architectural quality attribute.
Understanding business processes, IT, and service manageability
The earlier articles in this series emphasize the importance of enterprise-wide analysis of existing technology, business practices, and services. This remains a crucial activity if there is a requirement for EA manageability. The following sections describe this in more detail.
Tools and techniques
Fortunately, designing an EA is not an entirely new endeavor. There is help available, and a few good sources are
- The Open Group Architecture Framework (TOGAF)
- Enterprise Unified Process (EUP)
- Zachman Framework
The use of these tools and techniques can assist in articulating the EA vision with respect to manageability. In particular, the use of EUP may reduce the cost of an EA project because it helps preserve existing investment in RUP.
TOGAF
TOGAF is a method for developing an EA and includes a toolkit. It provides a good framework for including manageability as an architectural quality attribute because it facilitates defining the structure of architectural components, their interrelationships, and principles and guidelines of design and evolution. TOGAF is essentially a method for developing an architecture, and it includes best practices, references to practical case studies, and development guidelines. Made up of three parts, TOGAF includes the method, a repository of models and patterns, and a set of guidelines.
One of the TOGAF deliverables is a set of target architectures derived by combining information about the benefits and constraints of the existing implementation along with requirements for change.
So, if manageability is not a requirement today, TOGAF provides the means to defer its implementation. In other words, the requirement can be recorded, modeled, and optionally implemented later. One further nice thing about TOGAF is that it can be downloaded by any enterprise for the purposes of developing an enterprise architecture for use within that enterprise. This also helps cut the cost of generating an architecture.
EUP
Another useful technique is EUP, which is an extension of IBM Rational Unified Process® (RUP®). The fact that EUP is an add-on to RUP helps reduce the cost of using it because existing RUP practices can be extended rather than replaced. Because of this, the recommended way of adopting EUP is to first use RUP and then migrate to EUP.
Just like RUP, the EUP phases can be used in a flexible manner. For example, a team can move from production all the way back to inception. Alternatively, a phase change can occur from construction to elaboration. The latter might be used when it is required to introduce or change some enterprise architecture requirements. An obvious example is introducing enterprise architecture manageability.
EUP introduces a number of enterprise-level disciplines including operations and support, as well as the seven enterprise disciplines:
- Enterprise business modeling
- Portfolio management
- Enterprise architecture
- Strategic reuse
- People management
- Enterprise administration
- Software process improvement
A fundamental difference between RUP and EUP is that the latter addresses the full IT lifecycle. RUP addresses only the software development portion of the lifecycle. A clear difference between TOGAF and EUP/RUP is that EUP allows you reuse the RUP investment. This might represent a useful cost saving.
Zachman Framework
The Zachman Framework is also useful in the context of an existing EA because it can be used to express the elements of that EA. So, if the requirement is to add support for manageability, then Zachman may also help get past the starting point.
Zachman is another framework for EA, and it provides a formal and structured way of defining and modeling an enterprise. The Zachman framework features a two-dimensional classification model based on the intersection of the six basic communication interrogatives (what, how, where, who, when, and why) and the six distinct model types, which relate to stakeholder groups (visionary, owner, designer, builder, implementer and worker). The purpose of the two-dimensional Zachman model is to provide a holistic view of the enterprise being modeled.
Zachman is most often used for reviewing systems architecture or enterprise-level technology. It differs from TOGAF and EUP because it is popular with IT architects while not being of much interest to technology developers or user communities. On the other hand, it can be used to evaluate the software architecture of a given organization. Some critics of Zachman reckon it generates too much documentation, but it might be of use to an organization considering the issue of EA, that is, an organization that wants to understand and possibly improve its existing architecture. So, Zachman is of benefit to an organization that is planning its architecture but not overhauling an existing architecture.
Learning resources
Both Geronimo and WebSphere® Application Server are worthy of study in the context of EA manageability.
Geronimo
Rather than just discussing theoretical considerations, Geronimo already implements some of the ideas described in this article. Based on Java Management Extension (JMX) and the concept of inversion of control, every object in the Geronimo kernel is an MBean. Services in Geronimo are described using GBeans, which are specific to Geronimo and (surprisingly) are not MBeans. GBeans are themselves manageable units that follow a specific finite set of states including starting, stopped, failed, and so on.
Geronimo is a compliant application server, and it can host services that span more than one machine. Clearly, the built-in manageability of such services is a compelling argument for looking at this technology in the context of EA manageability. The reason for this is because Geronimo exists and already features manageability from the ground up. Taking this as a starting point, close study of Geronimo can help inform the approach to arriving at EA manageability.
WebSphere Application Server
Like Geronimo, WebSphere Application Server is also a compliant J2EE product, and it includes comprehensive management support including the following:
- Scripting
- Problem determination
- Server management
- Session management
- Deployment
- Resource configuration
WebSphere Application Server also supports the J2EE management application program interface (API), which allows users to programmatically execute the management operations. The choice of Geronimo over WebSphere Application Server is mostly a procurement decision. It's not the purpose of this section to recommend either one -- each has its merits and its followers.
Milestones
The key first step in understanding EA manageability is defining appropriate requirements. You can use the Skills and competencies section as a template for some requirements to get started. Defining manageability in terms of EA consists of the details of the associated quality attribute.
The next major task is to understand the EA, and you can use one of the tools described earlier for this purpose. If a given organizational aim is to develop an EA, then you can use either TOGAF or EUP. If investment has already been made in RUP, EUP may be appropriate because it is an extension of RUP. On the other hand, if it is required to understand the EA, then Zachman may be a suitable choice.
Creating an EA with manageability as a quality attribute is a challenging task. However, existing tools and techniques indicate that this is a project that can be ongoing in nature. Also, the major elements of manageability are well understood, and some platforms and products already provide good support for some of the requirements.
If you assume that an EA with manageability has been created, how can you gauge its success? To answer this, you must look back to the requirements and see if they have been fulfilled. Answers to the following questions are a good guide:
- Are the elements of the EA instrumented for monitoring and control?
- Is automated operation possible?
- Are the elements of the EA event driven?
- Is the EA model based?
Answers to these and other questions need not be provided all at once. They can be posed over a period of time to determine the extent to which the EA is manageable.
Summary
As the trend towards SOA accelerates, the need for manageability will most likely increase. This is because SOA may well strain existing IT resources to the breaking point, and SOA is only just getting started. So, the decision to investigate EA manageability is important, and its importance may grow with time.
Resources Learn
Get products and technologies
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational®, Tivoli®, and
WebSphere®.
Discuss
About the author | | | Stephen Morris is the CTO of Omey Communications in Ireland. For the past 20
years, Stephen has worked for some of the world's largest networking companies on
a wide range of software projects, including J2EE/J2SE-based network management
systems, billing applications, porting and developing SNMP entities, network
device technologies, and GSM mobile networking applications. He is the author of
Network Management, MIBs and MPLS: Principles, Design and Implementation (Prentice Hall PTR, 2003), as well as several articles on network management and other topics for InformIT and OnJava.com. |
Rate this page
| |
