The New Ility
One of the -ilities people try to build into their software is maintainability. It’s been that way for as long as I can remember (although as I grow older, my memory grows shorter).
As the pace of change continues to increase, the necessity for IT organizations to be able to deliver on demand also increases. We’re on the look-out for anything that can enable this: continuous integration, heavy test automation, Behavior-Driven Development, DevOps, automated deployment, resilient infrastructures that can adjust dynamically to changing workloads or server outages, reactive architectures that flex under user demand.
A maintainable application may not be up to these challenges. The idea of “maintainability” implies that the application is a long-term artifact; a cathedral or a Great Pyramid. But keeping up with the demand for change may call for something a little different: Applications that can be discarded and replaced rapidly with no negative impact to customers, low risk, and low cost.
The situation calls for a new -ility: Replaceability.
Your first reaction may be, “We can’t do that.” You’re right. You can’t do that today. The appropriate question to ask when we want to do something that we can’t do today is this:
What would have to be true that is not true now in order to enable the New Thing?
Strategic and Tactical Assets
The first prerequisite that I can see is we must explicitly decide which applications are tactical and which are strategic. I think the idea of replaceability pertains to tactical assets, and not strategic ones.
If you have a well-designed SOA environment, you can start by assuming most of the applications in the “core” are strategic and most of the applications that interact with core assets through the service layer are tactical.
Most organizations don’t have a well-designed SOA environment. How can we begin if we don’t have that advantage? I think we can consider what types of IT assets are central to our business operation.
Here’s a suggested taxonomy, for discussion purposes.
- Data-centric operations
- Transaction-centric operations
An organization for which data is central to operations is data-centric. I will suggest these types of businesses, for starters:
- an advisory company for investors
- a company that collects information about vehicle histories
An organization for which high-volume, fast transaction processing is central to operations is transaction-centric. I will suggest these types of businesses:
- a social media service
- a mass marketing company
An obvious objection arises to this taxonomy: All these types of businesses are centered on data in one way or another. Clearly, the investment advisory company collects and analyzes data about stocks, and the vehicle history company collects data about events in the lives of vehicles. But the social media company and mass marketing companies are in the data business, as well. The former sells information about users and their preferences, and the mass marketing company depends on scrubbed mailing lists or phone lists to maximize the response rate of mass marketing campaigns. Aren’t they all data-centric businesses?
The key as I see it is to look at the question from the perspective of IT operations. In the first two cases, the collection of data is critically important. It has to be clean, consistent, accurate, and readily accessible. Tactical applications are like windows into the data, and clients of the algorithms that make sense of the data. The data and the algorithms are the strategic assets in that case.
In the cases of the social media service and the mass marketing firm, there can be a great deal of noise in the data without affecting the business negatively. It’s more critical that they can process a very large number of transactions quickly. They don’t even require an ACID database. Dirty reads are okay. Updates that catch up “eventually” are okay. But the transaction processing has to be absolutely rock-solid.
Another difference pertains to the “stickiness” of the data. The investment advisor and the vehicle history reporter need to keep long-term historical data intact. The longer the history, the better the information they can report to their customers.
The social media service and the mass marketer don’t need to keep information about customer preferences or customer addresses and phone numbers for the long term. Those categories of information tend to be transient. People’s tastes change over time as they go through different stages of life. People relocate and change phone numbers from time to time. And it’s easy enough to start over; certainly not the same impact as for the performance history of an investment instrument.
Considerations for Strategic Assets
Once we’ve determined which IT assets are strategic and which are tactical, we can apply appropriate considerations to the selection and support of each type.
In my view, the following considerations apply to strategic assets:
- Vendor relationship: Partner
- Key product selection criteria: Unique features of a particular product
- Budget for support: High
- Cost of replacement: High
The new -ility, replaceability, doesn’t apply to strategic assets. We will intentionally lock ourselves into a specific product because of the special features it offers that help support our business needs. We won’t relate to the vendor as a customer, but rather we will establish a partnership arrangement with them. We need close and immediate support for anything and everything pertaining to our strategic assets. To get that, we’ll budget more to support these assets than we will to support tactical ones. We’ll also accept the fact that should the need arise to replace a strategic asset, doing so will involve significant effort and cost. We don’t plan to change strategic assets frequently.
An aside: What’s the implication for Agile development? Changes in strategic assets will tend to be characterized by low uncertainty, low time-to-market pressure, and a need for significant up-front analysis and planning. This is not the sweet spot for conventional Agile methods.
What does it mean to replace a tactical asset? For the investment advisory firm, the data and the analysis algorithms are strategic assets. Web-based or mobile clients are merely “windows” into those assets. These client applications should be replaceable quickly at low cost and with low risk. Replacing, say, a .NET webapp with a Ruby webapp should have zero impact on the central data store or on the code that performs investment analysis.
Considerations for Tactical Assets
In my view, the following considerations apply to tactical assets:
- Vendor relationship: Customer/supplier
- Key product selection criteria: Adherence to vendor-neutral standards
- Budget for support: Low to moderate
- Cost of replacement: Low
This is the area in which replaceability becomes a critical success factor for the enterprise.
Although most organizations lack a well-defined SOA infrastructure, each tactical application will have some way of interacting with strategic assets. In an established organization there will almost always be a range of different methods: point-to-point interfaces, file-sharing, SOAP services, RESTful services, RPC, cross-memory services…you name it. This model doesn’t depend on any particular technical implementation. Old technologies fit into the model the same way as newer ones.
The key point is we don’t want any baked-in dependencies on product-specific features above and beyond “plain vanilla” support for vendor-neutral standards. We expect to replace these applications from time to time, and when we do so we don’t want to hit a wall of technical issues. A web server is a web server; a rules engine is a rules engine; a SQL database is a SQL database. We don’t want to configure tactical assets in a way that will add cost or delay to their replacement.
An aside: What’s the implication for Agile development? Changes to (or replacement of) tactical assets will tend to be characterized by high time-to-market pressure and high means uncertainty, even if not by high-end uncertainty. This is the sweet spot for adaptive approaches such as Agile development.
What does it mean to replace a tactical asset? Let’s say the social media service grows from 100 million users to 1 billion users, and the document database they were using is no longer providing the transaction times they require. They want to switch to a graph database or a relational database. They need to be able to do this with a minimum of hassle. They will have to reformat the data; hopefully, that can be done with a script. But there are always “gotchas.” Our goal is to keep everything as simple as we can on the tactical level, to minimize the number and difficulty of the inevitable “gotchas.”
Enabler 1: Specification by Example / Behavior-Driven Development
You might argue that we’ve tried to replace applications in the past, and it was always a hassle. How many “it’s just a rewrite” projects have we lived through? I’ve lost count. I guess you have, too.
We need a practical way to be sure we haven’t overlooked some important feature when we replace a tactical application. As far as I know, there’s no magical way to do this. However, there is a technology that offers a pretty good partial solution: The text-based “language” known as Gherkin.
Gherkin is a specification for formatted text that is designed to support Specification by Example or Behavior-Driven Development. The interesting thing about Gherkin for purposes of replacing a tactical application is that it is technology-agnostic. The only thing you would ever have to change when moving Gherkin specifications from one platform to another is the line endings, if you were moving to or from Microsoft Windows. Any Gherkin interpreter on any platform can process standard Gherkin text files.
Gherkin won’t help if we’re replacing one database management system with another, but in that sort of replacement we don’t have the concern about overlooking a functional requirement. Gherkin can help with replacing a “window” application that accesses strategic assets. The user-observable behavior of the application can be captured in the form of Gherkin scenarios, which can then be used to ensure the new application supports the same functionality as the old one.
There’s no real cost involved in using Specification by Example or Behavior-Driven Development. These techniques are merely a question of self-discipline on the part of technical professionals. Gherkin interpreters for just about any platform and any programming language are free downloads. The value of these practices extends not only to clarity about requirements, automated functional checking, and dependable documentation, but also helps support the idea of replaceability for tactical applications.
Therefore, one way to help prepare the ground for separating strategic and tactical assets is to back-fill functional specifications for existing applications in Gherkin. This can be done incrementally over time.
Enabler 2: Separation of Concerns
In working with legacy applications, we need to pay attention to separation of concerns. In particular, the code that communicates across the “boundary” between the strategic and tactical worlds has to be loosely coupled with the rest of the application code. This applies both to strategic applications and tactical ones.
Consider the case when a social media service wants to replace the database management system. The strategic transaction-processing code should not be affected by this change. The only parts of that code that should be affected are the layers or components that directly interact with the database. Strategic functionality must be unaware of any changes to the database implementation.
Therefore, one way to help prepare the ground for separating strategic and tactical assets is to refactor legacy applications to ensure clean separation of concerns. This can be done incrementally over time.
Summary
To meet emerging demands for rapid change, IT organizations need to consider ways to enable very fast replacement of technical assets that are liable to be affected by changes in the market or in business direction. By separating strategic and tactical IT assets, we can take steps to ensure it will be easy, fast, and cheap to replace tactical assets, while still enjoying the benefits of tight integration with the special features of strategic products that support our business operations. Thinking about IT assets in this way helps us understand where to focus our budget and effort to achieve maximum value with minimal overhead.