Eight Technology Architecture Tenets for the Digital Age

A successful digital strategy requires not only a framework for identifying and prioritizing strategic technology solutions, but also the right tenets to guide architecture choices. After all, once you have defined whether or not the solution is strategic, you will need to specify the rules of engagement.

Will the proposed solution be disruptive or have competitive impact? If so, does the solution have the potential to be a capitalizable intellectual property asset? If not, is it a throwaway case? Will this tactical solution be maintained in the long term?

The formulation of tenets is key to the entire project. Tenets must be able to withstand the passage of time and survive the challenging trials that a project presents. They’re not meant to be changed easily, which is all the more reason to prescribe commonsense best practices.

There are exceptions, of course. For example, so commonsensical are some of these tenets that their motherhood-and-apple-pie appearance make them seem like nothing more than a collection of distilled clichés. Still, it’s essential to state tenets openly and unabashedly.

Let’s take a look at eight top tenets in defining a technology architecture today. In our view, these tenets represent the consensus of most companies, and while they will hold water under many conditions, they were selected under specific situations that might differ from yours. Clearly, the list is not exhaustive, and we recommend assessing the applicability of these tenets based on your circumstances.

1. Functionality requirements must be driven by the business requirements
This statement reinforces the need to ensure that business is involved from the start in defining the specific features and priorities.

2. Be architecture driven, not vendor driven
This is a Zen-like, “be-the-architecture” tenet. If the architecture is vendor-neutral then, and only then, do you approach vendors to ask how they can help fulfill your vision. This tenet would likely be essential for strategic solutions, but for a tactical development such as an ERP system, which is sufficiently commoditized across industries, you would do fine by following the lead of a vendor.

3. Try to use off-the-shelf industry standards and products for all commodity-level elements
In the late eighties, there was an Open Systems Interconnection (OSI) model that defined a seven-layer interoperability stack. While somewhat outmoded, this model is still useful in showing how the IT industry has been traversing the OSI layers toward commoditization.

We have seen companies who’ve spent an inordinate amount of time and effort developing their “own version of network protocols” or their own “very cool, in-house version control system.” Unless your company is a business where a new network protocol is deemed strategic, you’re better off having your team develop components that will create differentiating solutions at the top of the stack. It’s wiser to focus on providing value-added features not readily available on the market and leverages your company’s core competencies than to divert resources to requirements that can be easily met by an off-the-shelf product.

4. Choose best-of-breed
There are plenty of vendor suites, and naturally, vendors will try to plug in all kinds of modules and ancillary services under the guise of better integration. But follow the Sirens chanting “free extra modules” instead of seeking the best solution to your problem, and you would soon find yourself in hot water. Too often companies purchase “integrated” solutions from vendors that would eventually go the way of the Dodo. Don’t make this mistake. Define a vendor-neutral architecture to meet your company’s needs first before inviting vendors to help fulfill your vision.

5. Integrate before developing
Since you will be purchasing best-of-breed solutions, which will probably come from different vendors, you will have an integration challenge. Fortunately, we live in a time where service-oriented architectures, integration tools, and REST interfaces make this type of integration more feasible. Also, in line with the buy-vs-build tenet, it would be preferable to create a tactical or strategic solution by coupling various off-the-shelf tools as opposed to building a solution from scratch.

6. Minimize costs by driving reuse and convergence
This tenet is like being told to exercise, the health advantages of not smoking, or the importance of following a well-balanced diet—obvious advice that’s rarely followed. Similarly, when time-to-market pressures become unbearable, panic sets in, and companies end up choosing monolithic, expensive, non-scalable solutions. “Need a new campaign management product? No problem. Let’s buy that super expensive module from that company that invited us to the Ryder Cup last year! We’ll figure out later how to tie their customer database in with ours.” Sound familiar?

7. Place automation of core business functionality in back-end systems
It is better to have the bulk of the capabilities served via back-end engines rather than designing a monolithic front-end that implements all functions. Many front-ends that have attained a considerable size organically are now suffering from limited scalability. This is often due to the failure of their designers to move the business logic to backend engines. The front-end component should be focused on providing user interface capabilities such as interaction workflows, presentation level integration, and on accessing the backend business processes via services.

8. Simplify your range of technologies
As part of your architecture process, you should define what the de facto platforms are going to be. Given a choice between a technology already supported by your company and a competitive one, it is better to stick with the one that limits the variety of things you need to support. Again, exceptions can be made, especially if your solution is considered strategic and disruptive. We’re not saying that you can only have one database solution or use only one programming language. Strive for simplicity, but not to the point that you become simplistic.