An asynchronous relationship is a type of integration between two or more systems, or components within a system, that enables data to be exchanged without requiring an immediate result or action to be performed; a result is expected at some later time but does not immediately follow the request. The calling system has the ability to wait indefinitely by maintaining state until the partner system completes its processing.

Asynchronous relationships are critical to enterprise software, because they allow integrating partners to work together to solve complex problems more quickly and to develop scalable, long term architectures. This special type of relationship in effect enables integrating partners to use complex message exchange patterns (MEP) to manage the angle of approach and distribution of work and logic in the overall system that is the result of the integration.

For the enterprise business, the asynchronous relationship provides important benefits in speed of solution development and system longevity.

What are the benefits of the asynchronous relationship?

The asynchronous relationship provides many structural and organizational benefits:

• Independence: individual systems or components are free to choose their processing strategy, including important variables of scheduling, throughput, and processing speed. Since many enterprise software use cases require accuracy, not speed, the asynchronous relationship breaks this important and frequently unnecessary dependency.
• Backend implementation: systems integrated by this approach leave the door open to a vast number of choices for implementation. The architectures of backend systems can be completely different yet integrated using an asynchronous approach.
• Request size: since the asynchronous relationship frees systems and components from response time requirements,  request size can be as big as necessary. This is a critical, long term strategic advantage for system roadmaps based on this approach.
• Joint development: using complex MEP, logic required for processing can be distributed between systems. When applied correctly, following strong encapsulation principles fundamental to good architecture, this powerful aspect of integration enables separate teams to work together, cooperatively, to overcome big challenges and deliver great solutions.
• Speed of implementation: asynchronous relationships provide powerful tools like joint development that enable software teams to complete project functionality much more quickly.
• Roadmap: implementation independence, unlimited request size, and other benefits of the asynchronous approach can create high flexibility and long system lifecycles.
• Outages: recovery from system or component unavailability due to operations issues or maintenance is much simpler with asynchronous integrations; partner systems simply wait until the services recover or are brought back online following maintenance.
• Aggregation: because they remove response time requirements, asynchronous systems enable downstream systems or components to accept a single request from the upstream system, and in turn process many steps to complete the request. For the upstream system this means the logic involved in relating to the downstream system is greatly simplified.
• Rollback: like aggregation, rollback -compensation for prior steps in case of failure- is another key benefit an asynchronous downstream system can provide. Rollback can take as long as necessary and can even include manual steps. Again this means greatly simplified logic for the upstream system relating to the downstream system.
• Encapsulation/characterization: the asynchronous relationship naturally leads to distributed systems and processing, so that individual systems or components can build very strong encapsulation and characterization. This enables system owners to draw very clear architectural boundaries between systems, contributing to long architectural life cycles.

Ultimately, these benefits are valuable because they are extremely powerful business drivers for the enterprise; they enable the software team to quickly deliver strong, forward looking functionality and build positive synergy of successful delivery across the organization. This is the positive spiral that is a principal goal of enterprise software development.

Keep It Simple: a good and elusive goal. The expression has never been so relevant or important as applied to enterprise software development. This special kind of software is both highly complex and highly abstractable, because of it’s many and diverse stakeholders; it’s production is often more an issue of finding consensus than of overcoming technical hurdles.

It’s ironic that Keep It Simple is itself a subtle goal. That’s because taking the highly complex collections of use cases that make up the underlying business driver justifying a development effort, create a complex scenario for the software project to address.

Architecturally, Keep It Simple means building a platform only to the point that it has the minimum structure required for the immediate need; in other words to meet the requirements of the immediate project, while at the same time leaving the field as open as possible for as many different future uses and directions in the future, as possible.

But from a software team perspective, this approach has a completely different and possibly more important meaning; this is the point of this post. An enterprise is a large, complex entity; it is a collection of businesses. When a software development project is justified by business drivers, it is often not the first time the enterprise as a whole has addressed these needs, and created a solution. These prior efforts were likely smaller in scale, lower in capacity, completed more quickly, or used to address a smaller, less complex subset of use cases than the current project. Maybe, and this is frequently the case, the previous effort was completed by a different team or different business unit within the enterprise.

This prior effort has lots of value. It can be used as a model, a template, for the current effort, for discussion, lessons learned, and as an example. The prior effort is a lever that can be used to launch a much more complex or capable version. It’s a discussion point that can serve as common ground for the analysts and developers, and all teams involved, in order to move much more quickly in the current effort.

Enterprise software projects are never complete, each project is more like a further iteration of itself, a widening and reinforcement of the paths that already existed. Keep It Simple represents this process. It is a statement of the strength of the opportunity for the software to fulfill it’s promise to advance the enterprise: if something is worth doing, do it rapidly to the margin it is useful and no more, and then wait for the margin to increase.

As defined in Enterprise Information Systems: Contemporary Trends and Issues (Olson and Kesharwani, 2010):

An enterprise information system (EIS) is any kind of information system which improves the functions of an enterprise business processes by integration. This means typically offering high quality of service, dealing with large volumes of data and capable of supporting some large and possibly complex organization or enterprise. An EIS must be able to be used by all parts and all levels of an enterprise.

Because of the combination of “any kind of information system,” with the requirement that the EIS “must be able to be used by all parts and all levels of an enterprise,” means that EIS will always be unique: each is a combination of products and components, some of them large and standard such as SAP, but others highly specific to an industry, vertical, or market. That EIS are unique makes sense also from the perspective that ultimately they exist to support business strategy and value proposition, which are inherently unique.

Some level of internal production is required to create these systems. It’s required in order to set strategic direction, to determine system composition, and usually is required to achieve integration/interoperability between separate components in the overall system. All EIS are internally produced.

For these reasons, I use the term EIS to refer to internally produced enterprise systems built in support of strategic business objectives.

Enterprise software differs from other forms of software mainly in the number of stakeholders and the diversity of their perspectives. The characteristics that make that software valuable and useful are, as a consequence, also many and diverse. For the organization developing enterprise software, these characteristics represent aspects of focus; they must deliver each to be successful.

The diagram above organizes those aspects along a scale of value corresponding to stakeholder perspective.

The aspects themselves are identical for both external vendor and internal software development, but have specific meaning for the IT team embedded within the organization. They are:

1. Functionality: Functionality is the object of the software development effort- a new GUI, web service, integration point, or any other aspect enabling an enterprise to move forward via software.

2. Performance: Performance is the throughput and responsiveness of the system; for example the speed of a report rendering.

3. Availability: Availability is the uptime of a system, to the extent that it is impacted by outages and high calculation volumes.

4. Scalability: Scalability is the potential of a system to grow its calculation volume limits and the relative ease of doing so.

5. Extensibility: Extensibilty is the potential to build or expand the existing system to meet new requirements- for example, adding service type inventory to a product only catalog system.

6. Monitorability: Monitorability is the ease of visibility of the health indicators for a system, such as a load indicator available for outside use via SNMP.

7. Manageability: Manageability is the ease of support operations around the system.

8. Security: Security is the ability of a system to allow access to the right resources, at the right time, for the right users.

9. Auditability: Auditability is the potential to track the history of user and system interactions, and any other calculations within the system.

10. Maintainability: Maintainability is a highly structural aspect of enterprise software development, indicating the effort required to keep a system healthy and functioning correctly.

The pyramid concept has specific meaning for the embedded IT team developing software from within the enterprise. The larger organization likely values the software they’re developing only in terms of the upper areas of the pyramid- specifically, functionality. But, in order to deliver functionality in a timely and sustainable way, the IT team itself must focus on all activities in the diagram.

The scale on the right side of the diagram indicates the source of value of each area within the pyramid. From a business perspective, value increases upward in the diagram. Structural value that is essential to the system but likely not visible to the business, increases downward in the diagram.

For the software development effort to be successful, the IT team must focus on the increasingly structural lower areas of the pyramid. Without focus on these activities the IT team will experience budget atrophy or be limited to short term, low impact projects.

This is a paradox. How can the internal IT team overcome the burden of sustained effort that is invisible and not valued, in order finally to be able to deliver visible business value?

The answer has two parts. The first is that the team must have a balance of crucial factors, including good management, good leadership, good teamwork, good process, good approach, and good prioritization.

The second is synergy. By delivering the lower areas in the pyramid, the IT team develops reputation as well as a platform for increasingly rapid delivery of functionality. This is a positive upward spiral that can evolve into an enormous source of benefit and growth for the entire enterprise.

In business terms, an enterprise is a large group of people that can come together to form an effective business on a large scale. In fact it is more like a grouping of groups. Technology has been instrumental in helping larger and larger groups form teams that work well together. Operations software that is developed within the organization itself has the potential to be a highly strategic aspect of effective team development.

Imagine a company that designs and builds gyroscopes. Gyroscopes today are in demand as the technical uses for them has increased, and at the same time, a strong market exists for smaller, faster and more accurate technology. At a certain point the company will look to enterprise software to help manage  their design and manufacturing processes. But these processes are inherent, and custom, to the company; they are what enables the company to compete in the markets it chooses. For example, if the company is based in the U.S., they may work with dozens of overseas vendors. Making these relationships work well is likely a strategic aspect of the company’s value proposition, and it’s natural the company will look for enterprise software to optimize this aspect of its business. No COTS product provides this strategic benefit, but if the company chooses the product stack well, it can be extended, and developed, to precisely meet the strategic requirements of that enterprise. And, the most qualified people to do the work of the customization are ideally the people that know the most about the unique business domain- the people that are in the organization chart of the company.

Operation software development is the long tail of software written for the enterprise, build on the ERP, PLM, OSS etc. frameworks from SAP, Oracle, Redhat, and many others. Depending on industry vertical, this software is written more and less generically, but does not immediately meet the need of any (non-commodity based) company. Instead it must configured and customized to meet and develop with any particular industry name. Generally, the vendor steps in to offer consultant based software development services including Business Analysts, Requirements Developers, and Software Developers; it is an expensive but still marginally worthwhile effort. But, instead, the enterprise may choose to develop the custom software extensions of the commercial or open source framework. This enables the company to save the overhead (and profit) of the vendor, and in some cases much more importantly,  the intellectual capital created by the effort to produce and manage the custom software; this may include IP created in any phase of the SDLC, from concept to installation.

This is the value proposition of operation software developed within the enterprise.

Actually this is not the first post. But it is a restatement of the original.

IT, Information Technology, is not quite the right monikor for what this common area- in telecom and communications, health care, manufacturing, entertainment, etc. has evolved to become. After all, a game software developer for Electronic Arts is not considered to be in IT; however the languages, tools- and most importantly, patterns and architectures- are very, very similar. If you are an IT specialist reading this now, consider the network, server, and software infrastructure of a massively multiplayer online game, compared to the same infrastructure for the Apple Store or a ULS like Royal Bank of Canada.

IT has become so large and encompassing that it’s difficult to define, as demonstrated by the erosion in the CIO position; today everyone is connected to IT somehow. It’s almost a currency, and is a subject that defines the modern human experience.

I’m here to write about my experience, and to document my ideas for IT systems for business that are developed within those businesses, specifically for that business’s domain- the long tail.

This is the first post on this site. The purpose is to provide a location for articles detailing my approach and experience in enterprise software, particularly regarding operation support systems and the strategic role they can play.