In this fourth part of our Technology Assessment Framework IT Infrastructure series, we look at the six key areas to consider when assessing your application architecture’s health.
Whether your company is a vertically integrated, heavily regulated electric utility company or a consumer-packaged-goods business, the health of your application architecture is crucial to functioning, competing and surviving as a business.
And while different types of businesses have different application needs, evaluating application architecture health comes down to six key areas for every business: user satisfaction, financials, architecture, development, operations and controls.
Let’s take a closer look at each:
1. User Satisfaction
User satisfaction includes both how happy your employees are with the applications driving your business and how well those applications meet your customers’ needs.
If your employees are unhappy, they will find workarounds or other less efficient applications that may put critical systems at risk. On the other hand, your employees might love the external, customer-facing applications because they know how these work.
But, those tools might not work well for customers. Too many clicks, unintegrated systems and cumbersome tools may frustrate them—or drive them to your competitors.
2. Financials
Naturally, you’re concerned about the costs of purchasing and implementing your application solutions, but that’s just the beginning. You need to keep an eye on the total cost to serve your customers, which includes familiar metrics, like support costs and costs per user, along with licensing costs, problem-ticket resolution costs, and lost opportunity costs if systems go down.
You’ll also want to look at your supply chain. How many people and applications do you need to support it? Think of each person in your supply chain as a representation of the potential for a separate technological solution. Can your current applications allow you to reallocate some people’s work, bringing down costs and increasing productivity?
Finally, don’t forget about benchmarks. While you may be pleased with your performance levels, your overhead could still be more than you need to spend on applications. Strive to make sure your investments add value, while also meeting targets.
3. Architecture
Your overall framework illustrates how well your applications support business processes. It may consist of a user layer customers and employees see and interact with. It may also include an integration layer, a core application layer, and a data layer that stores the information behind all of it.
But no matter how many layers you have or how you structure these, the most important question is: “Does my architecture support my business strategy?” An architecture that is too rigid to accommodate “game changers” like rapid growth, changes in ownership or market shifts can become a big problem. Some specific areas to consider include:
- How up-do-date is your architecture? — Mobile applications, the cloud, big data and the internet of things (IoT) are no longer “nice to haves.” They are now “must haves.” Your architecture needs to be ready to integrate these if it isn’t already.
- The lifecycle stage of your applications and your migration strategy — Do you have applications your systems no longer support? Is your architecture nimble enough to support new apps?
- Governance — Healthy application architecture isn’t just about technology—it’s also about having well-documented and well-understood governance documents that guide software selection and the right number of applications for your organization. Good governance is the key to avoiding the next consideration: “shadow IT” applications.
- “Shadow IT” applications — If you used applications in the past that didn’t meet employees’ needs and didn’t have a good governance plan to address problems, those employees may have found other applications on their own. Acknowledge you understand why employees added these, explain why the new tools and architecture will be better, and include them as part of the process as you clean up your shadow IT.
- Gaps and redundancies — Look for applications that don’t meet business needs or meet them poorly. Also, consider duplicate applications used for similar needs in different business units.
4. Development
Most businesses’ applications fall into one of three categories: distinctive, cost-competitive, and foundational. Understanding the difference can help decide where to spend development resources.
Distinctive applications are typically consumer-facing tools that touch customers, make money and grow your business. The best example of cost-competitive applications is one that drives your supply chain. A foundational system might be your accounting tools—you can have the best accounting system in the world, but it probably won’t help you sell more.
Here’s how it might work: If you have a well-established brand, you don’t need to spend a lot on new apps to build distinctiveness. Your cost-competitive apps may currently function well, but they have the potential to add more value with a modest investment. But, if your foundational apps keep you from doing your work, you may want to put more money into them. It all depends on your business’s needs.
5. Operations
When thinking about your operations, think about how well you can recover from an incident. Also, think about which incidents could be the most costly. Assessing your risk profile helps, as does understanding operational recovery and disaster recovery.
Operational recovery means having systems in place that allow your operations to continue seamlessly, despite a failure in your system. Disaster recovery means coming back from an incident that caused you to shut down.
Disaster recovery isn’t cheap. One study shows a significant interruption can have a two percent impact on market share that requires a two-to-four-year recovery time. Obviously, you should design your architecture to support operational recovery as much as you can. But, it should be flexible enough for disaster recovery when operational recovery is not possible.
6. Controls
Remember the example of the vertically integrated, heavily regulated electric utility company at the beginning of this blog? For a business like that, keeping track of application documentation, installation costs and qualifications is essential.
But in today’s world, every business needs to make sure their application architecture is not just compliant but secure—and that your technology solutions solve your business problems, not creating new ones.
Nobody Plans to Fail—They Fail to Plan
You invested heavily in your suite of applications, but your initial investment does not ensure success. Business requirements change. Companies buy and sell other companies. Markets shift. Disrupting technologies change the landscape. When you have a healthy application architecture in place, it positions your organization for long-term growth and sustainability without putting employees and customers at risk.
