Part of a series.<\/a><\/em><\/p>\n 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.<\/p>\n 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.<\/p>\n Let\u2019s take a closer look at each:<\/strong><\/p>\n User satisfaction includes both how happy your employees are with the applications driving your business and how well those applications meet your customers\u2019 needs.<\/strong><\/p>\n 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 <\/strong>know how these work.<\/p>\n But, those tools might not work well for customers. Too many clicks, unintegrated systems and cumbersome tools may frustrate them\u2014or drive them to your competitors.<\/p>\n Naturally, you\u2019re concerned about the costs of purchasing and implementing your application solutions, but that\u2019s 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.<\/p>\n You\u2019ll 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\u2019s work, bringing down costs and increasing productivity?<\/strong><\/p>\n Finally, don\u2019t 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.<\/p>\n 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.<\/p>\n But no matter how many layers you have or how you structure these, the most important question is: \u201cDoes my architecture support my business strategy?\u201d An architecture that is too rigid to accommodate \u201cgame changers\u201d like rapid growth, changes in ownership or market shifts can become a big problem.<\/strong> Some specific areas to consider include:<\/p>\n Most businesses\u2019 applications fall into one of three categories: distinctive, cost-competitive, and foundational. Understanding the difference can help decide where to spend development resources.<\/p>\n Distinctive<\/strong> applications are typically consumer-facing tools that touch customers, make money and grow your business. The best example of cost-competitive<\/strong> applications is one that drives your supply chain. A foundational<\/strong> system might be your accounting tools\u2014you can have the best accounting system in the world, but it probably won\u2019t help you sell more.<\/p>\n Here\u2019s how it might work: If you have a well-established brand, you don\u2019t 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.<\/strong> 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\u2019s needs.<\/p>\n 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<\/a> helps, as does understanding operational recovery and disaster recovery.<\/p>\n Operational recovery<\/strong> means having systems in place that allow your operations to continue seamlessly, despite a failure in your system. Disaster recovery<\/strong> means coming back from an incident that caused you to shut down.<\/p>\n Disaster recovery isn\u2019t 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.<\/p>\n 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.<\/p>\n But in today\u2019s world, every business needs to make sure their application architecture is not just compliant but secure\u2014and that your technology solutions solve your business problems, not creating new ones.<\/p>\n1. User Satisfaction<\/h2>\n
2. Financials<\/h2>\n
3. Architecture<\/h2>\n
\n
4. Development<\/h2>\n
5. Operations<\/h2>\n
6. Controls<\/h2>\n
Nobody Plans to Fail\u2014They Fail to Plan<\/h2>\n