Choose one word to describe your company\u2019s technical architecture and it would likely be \u201creally complicated.\u201d\nOkay, that\u2019s two words, but most technical architectures really are really complicated. Figuring out how to simplify and improve them? We\u2019ll need to repeat \u201creally\u201d a few more times: That\u2019s really, Really, really complicated.\nOf course, when anything is that complicated \u2014 or convoluted \u2014 it helps to break things down before building up an improvement plan. Here, we do just that, helping you hack off a few of those \u201creallys\u201d so you can put a practical game plan together to ensure your company\u2019s technical architecture best serves the business.\nUntangling technical architecture\nA previous installment in this series provided a framework for describing technical architecture, breaking it down into three portfolios and their sub-portfolios:\n\nApplications: systems of record, interfaces and integration, and satellite apps\nData: both structured and unstructured\nTechnology: facilities, infrastructure, and platforms\n\nThe next installment added the idea that technical architecture requires two complementary perspectives: the portfolio view and holistic design. It also provided guidance for evaluating the health of the components that make up the architecture.\nAnd it showed how to connect the technical and business architectures, specifically through the \u201cbusiness capability model\u201d (BCM) \u2014 a business function taxonomy to which each application in the technical architecture maps.\nTogether they let you identify, categorize, and rate what you have.\nBut to get from here to establishing an effective plan for improving your technical architecture, you need to determine, for every component in each portfolio and sub-portfolio, its disposition \u2014 how it needs to change \u2014 and the priority for making its disposition happen.\nThe specifics depend on which portfolio and sub-portfolio you\u2019re dealing with. Here we break that down, from the bottom up.\nFacilities and infrastructure\nIn improving technical architecture, establishing priorities is always your first priority. Score each component\u2019s health using the process, framework, and criteria described in the last installment. Score its importance based on how many applications rely on it. Multiply health by importance to compute a priority index for each component. Visualize the result as a heat map, where the redder the component the higher its priority.\nDispositions come next. For facilities and infrastructure, your disposition choices are:\n\nRetire: While it\u2019s unlikely, it is possible you\u2019ll identify facilities or infrastructure that aren\u2019t in use. Turn them off, shut them down, and cancel any leases or support contracts.\nUpdate: You might find components of your facilities or infrastructure that are obsolete, unsupported, or otherwise in need of updating to more current versions of the same product. Update them.\nReplace: You might find a component that is obsolete, unsupported, and if there is a more current version available you don\u2019t consider it viable. Get rid of it and deploy a functionally equivalent but healthier alternative in its place.\nConsolidate: It isn\u2019t unusual for a technical architecture to have redundant facilities or infrastructure components. Especially following a merger or acquisition, multiple data centers or networks often offer consolidation opportunities.\n\nYou now know, for facilities and infrastructure, what needs attention most urgently and what to do about the situation.\nPlatforms\nDetermining platform priorities and dispositions differs from determining them for facilities and infrastructure because platforms have far more interdependencies. A good way to deal with this complexity is to define stacks. A stack is a combination of platforms used by at least one application, including the server OS, development environment (including libraries), DBMS, CMS (content management system), web server, and supported browsers (assuming the application\u2019s UI is exposed through a browser), plus the operating systems on which the various platforms run.\nIt\u2019s worth noting that stacks are recursive: Platforms can rest on other platforms. It\u2019s also worth noting that some applications can also be platforms. SharePoint, for example, is an application that can also serve as a development environment for building custom applications.\nPriorities: A stack\u2019s health is the average health of its components, scored using the process, framework, and sample criteria documented in the previous installment of this series.\nIts priority? There\u2019s no infallible \u201cbest practice\u201d for this. An approach that cuts through the complexity is to identify the unhealthy platform that, if remediated, improves the most stacks the most. To illustrate, imagine you\u2019ve defined 60 stacks in your technical architecture. Also imagine the unhealthiest platform you have in production is Windows Server 2003 \u2014 give it a hypothetical health score of -1.5.\nIn this hypothetical example, imagine that raising its score to +2 moves 14 stacks from -1 to 0 and another 6 stacks from 0 to +1. That\u2019s 22 stacks improved by fixing Windows 2003 Server. Windows 2003 Server\u2019s priority index is 20 out of 60 stacks improved: 0.33.\nRinse and repeat for every platform component and you have a useful way to rank platform priorities.\nDispositions: Platform dispositions are similar to those defined for facilities and infrastructure:\n\nRetire: While it\u2019s unlikely, it is possible you\u2019ll identify platforms that aren\u2019t in use. Turn them off, shut them down, and make sure to cancel your license agreements and support contracts while you\u2019re at it.\nUpdate: You might find platforms that are unsupported or otherwise obsolete. Migrate them to more current versions of the same product.\nReplace: It\u2019s not uncommon to find a platform that is obsolete, unsupported, or, if there is a newer version available, you don\u2019t consider it viable. Get rid of it, deploying a functionally equivalent but healthier alternative in its place.\nConsolidate: It\u2019s a rare technical architecture that doesn\u2019t have redundant platforms in use. Between server OSes, DBMSes, integrated development environments, and so on, establishing those with the highest health ratings as company standards and migrating the rest to those standards can offer rich opportunities for simplification and improvement.\n\nData\nIn theory, data repositories should be considered independent targets for improving technical architectures. In practice, these are dealt with as part of application dispositioning, not as independent assessments and plans.\nExcept, that is, for an organization\u2019s data warehouses and other analytics repositories. These should be dealt as separate data-layer components. But because they\u2019re managed by the organization\u2019s analytics practices, they\u2019re Someone Else\u2019s Problem. You can safely exclude them from your evaluation process.\nUnless, that is, one or more platform layer dispositions affects an analytics repository.\nThat\u2019s one of those cases where the technical architecture becomes political.\nApplications\nNow it gets interesting.\nYou can score application health just as you scored the health of the components in the lower layers of your technical architecture: just average the evaluation criteria scores to get an overall application score.\nPriorities: It\u2019s not uncommon for even a midsize enterprise to have hundreds or thousands of applications in their portfolio, so establishing priorities one application at a time is impractical. Nor is establishing application priorities even a good idea. You\u2019re far better off considering priority as a property of business functions and the application mappings you\u2019ve already documented using the business capability model.\nIn most technical architectures, each business function is supported by one, or possibly two core applications, often modules from an ERP package or other broad suite.\nCore applications are surrounded by satellite applications that provide functionality missing from the core application. Satellite and core applications share and synchronize data with each other.\nIn addition, many business functions make use of utilities \u2014 applications that stand alone and require no integration with other applications supporting the business function in question.\nTo determine priorities, start by calculating a business function application health index as the weighted average health of the applications that support it, assigning a weighting factor of 10 to core applications, 3 to 7 to satellite applications, depending on each one\u2019s size and scope, and 1 for utilities.\nYou should already have the business function\u2019s health recorded \u2014 that was provided to you by the business architecture team as part of its BCM.\nYour top priority is the business function with the worst combination of business function health and application health.\nDispositions: Technical architects have more alternatives available for dealing with applications than with the lower layers of the technical architecture. Specifically, for each application you can:\n\nRetain: Continue to use the application, maintaining and enhancing it as business needs change.\nReplace: Get rid of the application, substituting a functionally equivalent but overall healthier alternative.\nRe-platform: \u201cLift and shift\u201d the application to a lower-cost but otherwise equivalent set of platforms.\nRefactor: Rewrite the application to conform to your technical architecture engineering standards.\nAdapt: If a platform is going to change (see platform dispositions, above), some applications will need to change with it.\nConsolidate: If an application is redundant \u2014 i.e., a functionally equivalent but superior application is in use elsewhere in the enterprise \u2014 migrate to that application, especially if it\u2019s been deemed the go-forward company standard.\nRetire: Unplug the application and cancel its licenses. If the situation calls for it, archive the application\u2019s data first.\n\nWhat about the cloud? The cloud is neither irrelevant nor important for this analysis until you\u2019ve finished assigning application dispositions.\nOnce you\u2019ve done this, if your technology strategy includes cloud migrations, the cloud might be the right choice for replacing, refactoring, or re-platforming an application.\nFrom priorities and dispositions to a plan\nMany technical architects, steeped in the waterfall approach, consider a roadmap, with a Gantt-chart-ish view of a disposition timeline, to be the most important artifact when planning technical architecture improvements.\nBut a roadmap is a relic of waterfall thinking. There\u2019s little point in planning technical architecture changes beyond the top priority platform or business function, until the top priority disposition plan is well under way. As we\u2019ve learned in agile application development, a plan made too far ahead is a plan that will be obsolete long before the time comes to get started on it.\nManaging technical architecture planning through an agile-style backlog is far superior to a classical roadmap.\nThere are two variations to this approach \u2014 platform-driven architecture and business-function-driven architecture. In the first, platform stacks take the place of agile \u201cepics\u201d in the backlog. The second builds its backlog epics around business functions.\nPlatform-driven architectural change: With this approach, one platform component will usually be selected, whether based on priority-setting as described above or some alternative that fits your organization better. Either way, planners will look for platform-level ripple effects (other affected stacks) and application-layer ripple effects (applications that make use of any of the affected stacks).\nMidway through implementing the top-priority platform disposition, technical architects will review current platform epic priorities in the remaining backlog and, if appropriate, modify them to fit changing circumstances, then begin the planning process for the next-highest priority epic.\nBusiness-function-driven architectural change: With business-function-driven architectural change, while it\u2019s true that correlation doesn\u2019t prove causation, functions where business and application health are both rated low are a reasonable place to look for application deficiencies that are causing business process bottlenecks.\nFrom the perspective of technical architecture, business-function-driven change begins with the disposition of the top-priority business function\u2019s core application and flows out from there to satellite application dispositions.\nIn parallel, the company\u2019s business architects will collaborate to design and implement process improvements enabled by the application changes.\nAs with platform-driven change, midway through implementing the dispositions of the top priority business function\u2019s applications, technical architects will review and, if appropriate, adjust backlog priorities and begin planning for the next-highest-priority epic.\nAnd in conclusion\nHad enough?\nTechnical architectures are complex. They have to be, because if you\u2019ve ever tried to document everything that has to happen in the business so it can design, build, sell, distribute, and support its products and services, you know the business is complicated.\nThis is, by the way, what your BCM does. It isn\u2019t uncommon for the first three BCM layers to list a few hundred business processes and practices. Likewise, it isn\u2019t uncommon for the applications mapped to the BCM \u2014 your application inventory \u2014 to number a thousand or more.\nThe process for documenting everything you have and planning whatever improvements are called for is time-consuming and expensive.\nBut that\u2019s okay, because not documenting everything you have and planning necessary improvements ends up being even more time-consuming and expensive.\nWhen your choices are pay it now or pay it later, the one thing you can count on is that paying it later is a whole lot worse.