Principles

A principle is a proposition (as we saw in Chapter 2). It serves as the foundation for a system of beliefs. As propositions, principles are abstract, but they should precipitate actions on the part of your teams that support them. Presumably, the principles are subsets or decompositions of your overarching corporate vision. If they’re not, your teams and department will suffer from a lack of alignment. You’ll be doing stuff that doesn’t matter. This is mistaking activity for progress.

The Open Group Architecture Framework (TOGAF), which was my architecture training and certification many years ago, publishes an in-depth way of approaching technology principles. You can take a shortcut and read Digital Principles or IBM’s old published principles.

Here is a set of principles that I’ve used in the past that you can adopt and adapt or use as a jumping-off point for creating your own:

• Primacy of principles

• Portfolio of development work aligned with strategy-driven architecture

• Compliance with laws, regulations, and standards

• Primacy of security, stability, and quality

• Management of technical diversity

• Data as an asset

• Getting value from data and services portfolio requires stewardship

• Software solutions created as public, scalable, open, interoperable, loosely coupled, governed services

• Design for failure

• Global cloud

Once you have stated your principles, unpack them to explain further what you mean. Stating “Global cloud” is not going to drive an ounce of change in your organization. So explain it further in more technical terms to folks who have a chance of finding practical avenues into actual projects, like this (as an example):

Services and applications of the platform should be built ready to run in the cloud and take advantage of such features as autoscaling and other auxiliary components while maintaining portability within the application structure.

Services should externalize configurations to account for such portability.

Infrastructure as code should be employed.

Services must expect to be deployed globally across multiple cloud data centers, and thus should externalize their localized values and internationalizeable application qualities. They should be stateless, and their data should be partitioned to account for multiple concurrent global deployments routed to geo-specific customer groups.

These start you down a path of creating a set of practices that derive from the propositions, are actionable, and are embodied by the principles. For example, from the preceding text, we can see that we need a few practices to realize that principle. Examples might include:

• Infrastructure as code

• Continuous integration/continuous delivery pipelines

• Service design review and governance

First we’ll need to pick one or more cloud providers and state what we’re using. Let’s say we’re going to use AWS. We can then make that statement.

We can also see what tools we might take advantage of to help realize the practice. GruntWorks, for example, could be used to support the infrastructure-as-code practice. Or you could decide to build this yourself using Python and CloudFormation. That choice might depend on other principles, or the outcome of a simple Build/Buy analysis, which will mostly reduce to this: build the things that are competitive differentiators for you and buy ones that aren’t.

These should give you an idea of what principles look like and how to write them so you can come up with your own:

Practices

These are the things people do on a daily basis. They are the processes, they way you get stuff done, the manner in which the principles are realized in your daily work. These might be things like DevOps or infrastructure as code or chaos engineering.

Tools

These are the specific instances of software applications that teams use as part of carrying out the practices. These should not be abstract but rather concrete, actual tools that force you to make a selection. “TensorFlow” or “Ansible” or “Log4J” or “Kafka” is the level of the values in your tools list.

It’s really important to think in terms of principles, practices, and tools. If you don’t, you’ll have less efficiency, less clarity, and less harmony. And you’ll have a collection of diverse overlapping tools and less alignment between people’s daily work and the strategic vision. Many shops are just collections of tools. The tools support the practices; the practices realize the principles.

Here you’re looking for three things:

• Missing elements, or logical gaps

• Mismatches

• Opportunities for improvement or upgrade

The Process Posture Map gives you a picture of either 1) elements of your current state that need to be supported or revised or 2) a practical map of how everything in your enterprise architecture will work together. So you can use this map as a diagnostic or alignment tool for the current state, or as an image of the Beautiful Future, an aspirational vision.

Example: NASA Strategy

For a good example of a CIO’s strategy report that is driven by vision > mission > strategic principles > goals > outcomes, check out the NASA CIO’s official strategy plan.

NASA is a government body and this plan is a public document, so it’s a bit different than what I discuss in this book. But it’s a textbook example of published principles (see “Principles”), clearly aligned business and IT goals, explicit IT goals, and so forth. If you think principles are too abstract to matter, note that while the NASA CIO states several of them, he does not state “innovation” as a principle, but instead states “secure,” “integrated,” and “cost-effective.” That would drive certain decision criteria and adoption practices for sure.

So this is a great document in terms of making the process clear. Within a business setting, however, it’s less likely that long-form written documents such as this would be the preferred format. I’m not sure how many businesspeople read strategies like the one from NASA, and it’s a bit more old-fashioned than many tech companies would want to see—NASA has no competitors in a sense, and is a government agency. It’s clear to me that publishing a five-year tech strategy in a tech company is only for full-on bureaucrats; it’s the kind of thing that’s irrelevant before it hits the streets. So we try to make ours more modular and easier to update on occasion, and keep the horizon tighter. But sometimes you’re doing a turnaround job modernizing legacy systems, and those are the kinds of internal things that will take three to five years, depending on the damage. I just point out this NASA one because it is texbook, and you can take it under advisement. Alternate perspectives help you shape a rich strategy.

Current and Future Model

There are whole books, fields of study, and certificates on Six Sigma, process improvement, efficiency experts, process mapping, process automation, and the like. If you have the time and inclination to learn more about those areas, that’s terrific. I recognize that those are important to really helping drive process change.

But for an architect, or for a Strategy Deck, you can get 80% of the way there with 20% of the work. People feel the pain every day of what’s broken. You learn about DevOps, or site reliability engineering, or data science, and have an idea those might help you transform from your current state to a better one.

There are three things you can do to help you do “process optimization lite”:

1. Examine the technology landscape for trends in new practices.

2. Make a Process Posture Map for your current state practices.

3. Make a Current State and Future State Operating Model.

You can include in your Strategy Deck something that helps your managers or leadership team understand the current state for what it is and see where you want to go within a new operating model.

Process Posture Map

The first step in a Process Posture Map is listing your processes in a pretty and organized way within a slide deck. Figure 6-1 shows an organized example of four main categories, with their processes under each.

Then assess the processes in your own mind and validate your thinking by talking with others to assign the process a posture. Assign one of the following five tags to each process:

Start	We do not do this in a meaningful or established way as an organization, but should define how we want to do this and begin to implement that.
Continue	This capability may require the normal continuous improvements of the local leaders but is generally is on track.
Invest	We have a nascent activity here that may have strong roots or certain strong practices and potential, and we would realize gains if we focused and grew the capability.
Assess	We have an ostensible capability here, but it should be examined for efficiency improvements in some areas.
Revise	This is clearly an ailing or weak capability that must be overhauled.

As an example, your Posture Process Map might look like Figure 6-2.

Figure 6-1. Organized list of processes

Figure 6-2. Initial Posture Process Map

What we’ve done here is divide the world into MECE categories (see “MECE”). This figure represents the set of processes within the category of “Managing for Business Value.” We then can make a list of each business process within that. We state the goal of the business process and the value it brings. This acts as a definition of terms and allows you to see what your organization does. You might also add a column for the business process owner if there is one. If not, that might be a sign that you need some additional maturity in that process. Finally, we have the “Action” column. Using values from the table, state your recommended action.

At this point, you will have essentially created a slate of work. You will have a list of all your processes, shared definitions, and some of them that you need to go fix. Of course, process reengineering is an entire field of its own that is beyond this book’s scope, but what you can do with this is consider the following:

• How mature are your processes in general? Do you have a lot with the “start” tag, which indicates that you aren’t doing that process at all yet? Maybe you don’t do change management or service governance in any kind of formal or explicit way and you can see benefit in instituting such a process.

• How extensive is the damage? Do you have a lot of processes with a “revise” tag?

• Recall Michael Porter’s Value Chain (see “Value Chain”)—a purposeful network of business processes that, when designed together, cumulatively transform a set of inputs into an output of greater value to customers and deliver it to them. How well do these processes work together? As a collective set, are they MECE?

The point is that now you have the basis for a conversation. On your own you won’t go off and just start reengineering all the weaker processes. But you can understand how much others agree with your assessments, and gain another perspective that helps focus your strategy in the areas most beneficial to your business.

Again, process reengineering is a vast field, and we can’t cover everything here. If you have the budget and inclination, you can hire a firm to examine all your processes and rework them. If you need to or want to do it yourself, I recommend getting familiar with Lean Six Sigma, which is the most widely accepted, popular, and rigorous method for process reengineering. You can start with the Six Sigma Handbook by Pyzdek and Keller (McGraw-Hill)—it’s accessible, practical, and comprehensive, and it gives you some tools to help make your “poor person’s process reengineering” more rigorous and standard. And, if you get super-excited about this stuff, it will help you get a Green Belt or Black Belt certification. My custom approach to this is called Scalable Business Machines, which we cover in Chapter 7.

The Principles, Practices, Tools Sankey Diagram

A Sankey diagram is a way of showing how energy flows in a system: what direction and in what magnitude. I’ve adopted Sankeys to show myself and my teams that our principles all had at least some practices to realize them and those practices were all realized by one or more tools.

Figure 6-3. Current and Future State Operating Model

Using the diagram is fun, makes a neat visual to share with teams, and is a good way of checking the holistic integrity of the departmental system you are creating. If you have some principles with no practices supporting them, they are just abstract platitudes. You need to either give up the pipe dream that the item’s actually a principle of yours, or go create a process that is capable of realizing it.

You can generate your own Sankey diagram with a free online tool called SankeyMATIC. It’s great. You enter your plain-text list of principles, practices, tools, and their magnitudes, and click a button. The diagrams it produces look like Figure 6-4 (it’s just a snippet).

Figure 6-4. Snippet of a Sankey showing principles, practices, and tools

You can see in the diagram how we have defined some principles, on the left: Automated, Global-Ready, Resilient. In the middle, we show which practices realize those principles. Then on the right, we have the list of actual tools we use to support those practices.

So when we say we want to be more resilient as an organization, it’s not a platitude: we do many real things to be more resilient, such as have a strong dev test practice. To make sure we are in fact doing dev testing and to set an expectation with developers about what tools they should use to keep us efficient, and to check that these elements all work together, we can see that in support of the dev test practice, we use the tools JUnit, JProfiler, YourKit, Postman, and SOAP UI.

You can also make Sankey diagrams easily in R for the more programmatically inclined. They’re a slick way to be sure you have all three factors working together and to what extent.

Business Process Mapping

Business Process Model Notation (BPMN) 2.0 is a standard notation created by the Object Management Group for representing business processes.  As you look at your challenging processes—the ones you want to improve—I encourage you to find someone on the team who is interested in this sort of thing and have him map out the current state process. Then examine it together with the team. Then, together, map a better future state process.

It’s not hard to do, but like drawing UML diagrams, it is sort of detailed, and you want to get the notation right. You can read the (very long) spec at http://www.omg.org/bpmn. Read books and get tools from various vendors (https://bpmn.io offers many wonderful examples, and Visio and LucidChart work well) to help you draw proper BPMN diagrams. Figure 6-5 shows an example.

You and your team likely have a pretty good idea where the headaches are. Pick a few of the processes, chart them on an ease and impact 2×2 matrix and pick a few to tackle. With a few smart go-getters on your team and some proclivity for lifelong learning, you might get 80% of what a process expert would in 20% of the time and money.

Figure 6-5. Example BPMN diagram

The Law of the Product of Probabilities

The law of the product of probabilities, or the product rule, is useful when you are examining your processes and practices for improvement. In the field of probability studies, particularly in genetics and biology, the product rule states that the probability of two or more events occurring together is the product of their independent probability of occurring. If you have two events in a process, each with a 50% chance of happening, the law of probabilities suggests that the chance of them happening together within a given instance of the execution of some process is 25% (because .5 x .5 = .25).

The trap is that we tend to take the optimization levels in each step in the process together as an average instead of as their product. It’s a very different picture, and a critical distinction when you’re considering how optimal your overall process is.

This is useful when we’re optimizing processes, because we tend to think things are better than they are as a result of thinking in averages rather than products. So it’s a good reminder that, unfortunately, we usually have further to go than we think.

We can think of the optimal scores as whatever metric we’re measuring at that point in the process. For example, you might have a deployment process or a software methodology, and you can arrive at metrics such as defect leakage or technical debt. Note that what we’re talking about here are independent variables within the same instance of a process. We’re not talking about repeated executions of the same step in different instances.

Here’s an example. Imagine you have a five-step process that you want to optimize, and you determine that at each step you have 80%, 85%, 90%, 85%, and 90% optima. It looks like you have a score of 86% overall, taken as an average. When taken as a product, however, the total optimization of the overall process is 47%: a very different picture.

Taken together, the Process Posture Map, the Current and Future State Operating Model chart, and the Sankey diagram of your Principles, Practices, and Tools give you a significant Roadmap, viewed through different lenses, for your organizational strategy—which your technology goals must align to.

Planning with Asset Classes

The APM is typically employed in organizations with too many applications to keep in your head at once, and where different knowledgeable, rational people might disagree on what the real boundaries of the different systems might be. If you have only six or eight technology products you’re doing an APM for, it’s probably overkill and doesn’t make sense.

But if you have a large, diverse, mature organization under your span of control, you might have a portfolio of 50 or 80 or 150 applications. In these cases, an APM is essential, and you may want to go an extra step and assign each application in the portfolio to an asset class.

An asset class is nothing more than a label from the following taxonomy, which you can use as a guide to suggest how to plan for the future of the applications in each category. These are presented in order of their presumed strategic value:

Strategic

Consider an application strategic if it represents a competitive advantage to your company, has many customers, is expected to grow, or is a competitive necessity. In these cases, you want to ensure it has strong market positioning, you’re applying your most innovative thinkers to it, and you’re focused on how to add value and create a diverse, rich platform around it.

Informational

If an application is informational, your most likely course of action will be to ensure it’s providing the most reliable data in the quickest way, that it enjoys a comprehensive data set, that it has a short turnaround time to get the data to support timely decision making, and that the data is properly surfaced where people need to see it.

Transactional

These tend to be the backbone of business, whether they are customer-facing or internal. There are only a few, clear things to do with transactional applications: to lower costs and improve throughput, ensure good-enough stability without overinvesting, and promote legacy modernization.

Infrastructure

If your team is a central organization providing infrastructure services to the rest of the business, your aim is to provide the quickest, most reliable support to the teams making the customer-facing, revenue-generating applications. Note the power of the asset classes: at AWS, compute and storage in the form of S3 or EC2 are not in the infrastructure: they are strategic, because they are competing diligently with other cloud companies. Unless you’re in the cloud provider business, it’s pretty certain that storage and compute for you belong to infrastructure. All too often, infrastructure teams get caught up in a “gatekeeper” mentality, rather than serving their internal customers with an enabling attitude. The thing to do with infrastructure is reduce costs to the business units, allow optimal business flexibility and choice to best serve customers, and provide some standardization. All too often, this standardization is interpreted by those in central infrastructure teams with a warden’s mentality—that is, as a means of keeping all the business unit prisoners in line. This is the opposite of what they should be doing. Standardization is intended to make it easier for the business units to count on something, to train and skill up appropriately, and to build their stacks on. If the infrastructure teams can provide and even create real value, that’s fantastic. Overindexing on standardization for its own sake to the detriment of customers is missing the point at best and an abuse of power at worst.

Capability Mapping

Depending on the current purpose of your APM exercise, you may want to take some additional time to create a capability mapping. This means listing out the applications that participate in a process or provide a business capability.

If an application supports more than one business capability, you will likely need to decompose it into modules or logical groups within that application to state which supports what capability.

Business and Technology Attributes

The core of the APM pattern (as I like to use it) is a spreadsheet (see Figure 6-7). Here you write the attributes you desire across the business and technology vectors; score each application against those attributes, multiplying for assigned weights; and then get a score for each vector for each application. That offers a quick way to reference what you should do with each one.

Figure 6-7. List of attributes with each application and the resulting recommendation

Here’s a set of technology attributes you can use to consider the level of technical risk each application poses. But of course feel free to modify it and add your own to best suit your purposes:

• Application code adheres to standards/strategy.

• Infrastructure adheres to standards/strategy.

• Data adheres to information management architecture.

• Application architecture is modular.

• There is an appropriate fault-tolerance architecture for application.

• Monitoring/management is complete.

• Automated testing is complete.

• Provisioning/deployment is automated.

• Training and documentation are complete.

• Security implementation is complete.

• Technology foundation will be relevant in three years.

• Application requires a sustainable skill set.

• Core application is stable and meets SLAs.

• Integrations are stable and meet SLAs.

These are focused on a legacy application portfolio with an aim toward rationalization. Using these will help you arrive at an overall recommendation.

Here are some business attributes you might consider:

• Application is a strategic differentiator.

• Application strategy is well defined, consistent.

• Application is mission-critical.

• System outage creates high customer impact.

• System outage creates high corporate impact.

• Application features align with current business needs.

• Application features align with future business needs.

• Ability to quickly add features to the system.

• Clear governance steers the application.

• Enhancement efforts are historically accurate.

• Business process is efficient with no processes defined to work around technical issues.

List these in your spreadsheet and do the math to score each application. The data page of your workbook should be constructed like Figure 6-8.

Figure 6-8. The data summary page of the APM spreadsheet

The data summary allows you to take a snapshot to put into your recommendation deck or the appendix of your Strategy Deck. It shows the long math that gives executives and yourself confidence that you aren’t just making stuff up, but have a measured, objective approach to portfolio management.

In the Quadrant column, you’ll assign one of four labels, depending on where each application lands in one of four quadrants in a 2×2 chart that looks like Figure 6-9.

Figure 6-9. The APM application assessment quadrant

After scoring your applications according to their attributes for importance and alignment to the business, you can chart them from a spreadsheet into a scatterplot and see where they land within this 2×2 matrix. Each quadrant suggests a different posture for each application and an attendant direction to take with them:

Grow/evolve/maintain

These are your highly aligned, strategically important, and low-risk applications. Assess their costs to be sure those are optimal and have not become bloated over the years. The risks, technical debt, and technology implementation are well positioned. Assess your investment plans with these applications to ensure you’re providing the right level to grow them, focusing on customer features, innovation, broader market applicability. Maintain them at high levels and support them with disciplined, strong staff and leaders who can act as operators.

Tolerate

These are your low-value/low-alignment and low-risk applications. They exist for some reason, to fulfill some purpose, but they don’t represent your future. You need to keep them around. Staff them with more entry-level people. Evaluate their costs to minimize them. You really don’t want too many applications in this quadrant, or it’s a sign of stagnation overall. Figure out what you want to do with these applications in the future. They aren’t a high priority, but you don’t want stuff staying in this quadrant forever either. Nudge them toward consolidation with other applications in the growth category; or figure out if you can nudge them toward the Retire quadrant, and get rid of them by changing a process or eliminating the related low-importance process; or outsource them.

Retire

These have low business alignment with high technical debt or risk to the business. The costs to keep them around may far outweigh their value to the business. These require you to make a hard call, because invariably there are nice people associated with these languishing applications, and some middle manager fearing for the future who will campaign to save these. But they’re almost certainly not worth it and no longer relevant. See if there is any function here worth saving that you can consolidate into another application, and scrap the rest and move on.

Reengineer/modernize/replace

These are the problem children, the question marks (see “Growth-Share Matrix”). They have both high business alignment and strategic importance, but have been mismanaged and allowed to devolve into a high-risk state of considerable technical debt. These are your workhorse applications that are crucial to your business, but that have unfortunately been “stewarded” by a revolving door of leaders who were interested only in short-term gains, investing in features and not architecture. Or they may have been underinvested by executives who mistook them too early for a cash cow, found themselves strapped for cash for long periods, or somehow deluded themselves into thinking that their sports car never needs a tune-up, new belts, an oil change, and tire replacement. You have another tough decision to make with these, and the outcome is hard to achieve, the planning complex, and the work long and hard. But it must be done because these are strategic applications that are important to the business. Their features are not inappropriate: they do what they’re supposed to. But they won’t scale in the current architecture to grow the business. Or they’re out of headroom. Or hasty decisions or full-on kicking the can down the road means they’re on an incredibly expensive and proprietary database platform. They need serious attention. So you must make a further business assessment and have many stakeholder conversations here to determine which quadrant to nudge them into: Can you replace them entirely with a new greenfield system, putting them in the Grow quadrant? That’s an expensive proposition and risky in itself, and you’re almost certain to incur the wrath of business or product managers who then worry about competing in the market since they won’t be getting customer-facing features while you overhaul the internals. Or do you modernize them piece by piece, service-enable them, move them to the cloud, and get them off TPF and onto a modern platform? That’s an even slower process, and potentially a death by a thousand cuts that you may not have time for.

This is the heart of the result of the APM work. But the APM in itself does nothing. It gives you a current state assessment, and then it is up to you to bring those findings before other stakeholders and use it as the start of some crucial conversations. It’s one easy-to-reference input into your overall strategy. You’ll need to pick based on the outcome of the APM what projects it suggests, and in what priority you should do them. Moreover, this approach to APM is helpful because it will give you a handy reference guide as you plan and prioritize the particular hot spots within each application. This could help you not only in long-term planning, but in quick-win, local remediation efforts as well.

Project Heat Map

When you come into a new organization, you will discover various projects under way. You may wish to apply the same general kinds of ideas from our APM to determine the value and alignment of these projects to evaluate their future. This idea is very similar to the Investment Map (see “Investment Map”), but with a finer grain and focus on projects. It’s simple. First, list the projects. Next, determine their net value to the business based on standard metrics such as internal rate of return (IRR) or anticipated return on investment (ROI). Then, examine the quality of the project based on metrics such as the technology employed, the capabilities it provides, and whether the costs are in line and the timeline is on track. Finally, you can plot them in a heat map. Figure 6-10 shows an example of your results.

Figure 6-10. Project heat map

This heat map is clear. If the project is of low quality and low business value, kill it. If it’s of high quality, stay with it. If there are question marks on the project, then the recommended actions to take are shown within the heat map, depending on where each project lands. The recommendations and colors stay the same across any given use of the heat map.

Use the APM deck to consult with key leaders in business and tech to form investment plans. It can be used well alongside the Investment Map and Process Posture assessments (see “Process Posture Map”) as you gather material for your Strategy Deck or an Ask Deck (see “Ask Deck”).

If you have further interest in this subject, you can check out the website of NASA’s Office of the CIO to see how it presents its applications with APM.