5 steps an Enterprise Architect can take to address adoption costs

These days, with the rise of software-as-a-service and the API ecosystem, many companies are taking the path of buying the services they need to meet their business requirements. Some companies subscribe to various features offered by a given service provider. Others aggregate elements from a variety of service providers to create a synergetic whole. The value proposition of paying only for what you use rather than buying a complete system en masse is hard to ignore.

Image

While project managers and business executives have an innate sensitivity to the cost of adoption, Enterprise Architects can become so focused on the technical details of system design that they overlook the actual cost of adopting the system they’re designing.

This is a real risk, and one that happens all too often. Fortunately, there are approaches Enterprise Architects can take to prevent such a mishap. The following are five steps an architect can follow to accommodate the cost when adopting an enterprise architecture.

1. Explicitly acknowledge that adoption is an architectural expense

The first step to addressing a cost is to recognize that there really is one. As mentioned above, architects can get so caught up in the technical details of designing an enterprise system that they may overlook the mundane activities that go into actually getting their designs to work. Instead, they’ll leave ownership of adoption costs to project managers and those in finance or accounting. Delegating such ownership to others is not a wise thing for an Enterprise Architect to do. Those most expert with an architecture’s processes and technologies need to be part of the cost determination process. Thus, Enterprise Architects will do well to work closely with finance and accounting resources within the company to estimate the adoption costs that go with the specifics of a system design. Once the estimates are in play, they can be modified as actual costs become apparent.

The important thing to remember is that the architect creates the cost of adoption and thus needs to own the cost of adoption.

2. Establish an adoption plan

A company implements an enterprise-scale architecture in a controlled manner by using a formal, documented plan that includes tasks, costs, and a timeline. While start-ups can enjoy some degree of improvisation in their development activity, mature companies implementing an enterprise architecture that can cost millions of dollars need the reliability that a formal plan provides. A standard adoption plan is the roadmap by which Enterprise Architects guide a business to the successful adoption of their system design while controlling the costs inherent in the design.

Adopting an enterprise-scale system without a plan ain’t.

3. Define the scope of adoption activity

Once you acknowledge that you do indeed have an adoption expense, you need to define the scope of adoption activity. Typically, there are a lot of people involved in adopting an enterprise system. This includes not only technical personnel but project managers, business analysts, and executives as well. These employees and the organizations to which they belong in the company need to be identified. Also, the activities they will be performing need to be documented within the adoption plan.

There are few things that impact the cost of a system adoption more than a mission-critical activity put on hold because a key player in the process is on vacation or has not been identified at the onset of the implementation. Knowing what relevant parties need to be doing and when they need to be doing it is important information. Just guessing who will do what, and when they will do it, is a costly way to approach system adoption at the enterprise level.

Adoption activities need to be well understood so that reliable estimates about the adoption cost can be made.

4. Quantify your cost model

When it comes to adopting an enterprise architecture, whether it’s an aggregation of capabilities provided by a software-as-a-service vendor or an on-premises monolith, there are many people doing a lot of work. Quantifying their activities into dollars and cents requires planning.

Anticipating and then accommodating the expense of adoption is tricky because the cost accounting is not as simple as reporting the subscription fee for a given third-party service.

At the least, the scope of work required to accomplish the adoption needs to be well understood and documented in the adoption plan described above. Also, a time reporting mechanism needs to be in place, and it always needs to be used. Once adoption time is captured, that time has to be converted into dollars, euros, pounds sterling, or whatever currency is identified for measurement purposes. The goal is to be able to quantify all expenses according to standard accounting practices. An expense that can’t be quantified in terms of money is non-existent. Thus, keeping track of it all is important.

5. Plan for a change and contingency

It is very rare for the system that’s on the drawing board to be the one that’s released to production. Things change; always have, always will. Part of accommodating the cost of adopting an enterprise architecture is to plan for change.

While it’s hard to know in advance how a system will change, it is possible to estimate the probability of change and calculate accordingly. This is called contingency planning. Examples of changes that might require contingency planning are a change in the way a service-provider implements a technology upon which your architecture depends or even changing the service provider itself.

The way you make the estimate is to determine the probability as a percentage. For example, “there is a 10% chance that a service provider will make an unanticipated change.” In this case, you increase the anticipated implementation cost by 10% as a contingency with the understanding that the amount put aside will cover the cost of the change.

Making such an estimate is much an art as a science. The important thing is to understand that change does happen, and it needs to be built into the cost of adopting an enterprise architecture.

Putting it all together

Adoption is a critical part of any enterprise architecture implementation. Just about all systems will require some degree of customization, either in code or by configuration.

Adoption is an expense that is always there, but one that is many times overlooked in discussions among Enterprise Architects. This type of discussion must take place. Without proper planning, the cost of adoption can become an unanticipated expense that over the long term becomes an excessive burden on a company’s financial resources. It’s a danger that can be avoided when the cost of adoption is anticipated at the onset of the implementation of an enterprise-scale system architecture.

There is always an expense associated with adoption, and it can be quantified. Don’t let anybody tell you differently.