Strategy and Tooling

You must ensure that your concept aligns with the business vision.  The best way to help connect those dots is to read this book’s companion volume, Technology Strategy Patterns. All too frequently I see architects and even CTOs who consider themselves as a kind of lead programmer. They are incredibly interested in the bleeding edge tool of the day. You can identify these people because they proudly and vocally will argue at lunch or over beers from a fervent viewpoint on the comparative merits of some particular JavaScript framework versus another.

We’re not interested in arguing over JavaScript frameworks. They don’t matter.

Raise your visor, think strategically, focus on getting the concept right, and you will have the best chance to define and create something maintainable, extensible, evolutionary, maybe even interesting, innovative, and groundbreaking.

Work at the level of the idea, the concept, and be ruthlessly pragmatic and detailed in your analysis. Argue the concept, the view of the world you are representing. This is where all the difference is made in a successful project versus an unsuccessful one, a costly and late one versus an efficient and on-time one.

Let the programmers pick their tools. They’ll be eager to become concept designers as soon as they realize how little difference is made between Ember and Angular.

There are only a few reasons that you want to weigh in on the tool selection:

• You have done homework the developers haven’t and have good reason to believe that one tool is more generally popular and therefore might be easier to hire for and will have better chances of living a longer life.

• You’re clear (without irrational bias) that a particular tool fits the concept well—for example, a graph database.

• You’re clear that a particular tool offers more portability and extensibility over another candidate tool.

• The tool represents a major new shift in direction or a wholly new kind of technology for your organization. If your organization has never done blockchain and has decided to go down that path, you need to do the homework yourself, read as much as you can, install what you can, and work with them a bit and create a comparative rubric with data to illustrate the thought behind your recommendation.

These things do matter, and should be squarely within your purview. Otherwise, tool arguments are nothing but minor border skirmishes, posing, and religious battles.

The fact that one language has duck typing and another doesn’t is interesting and quite important to a lot of people, typically those who might be designing languages or compilers and the like. To be clear, that is a fascinating and wonderful discussion to have, and any intellectual pursuit will only help you and your colleagues. I am only saying to not invoke minor technical differences in one framework or language and think you’re doing effective architecture. That’s all an important conversation, just not for us, not for these purposes.

One thing I do recommend is to study tools and processes from outside your industry. For example, if you work on business application software, look outside your domain and examine the software used by DJs, screenwriters, or composers for example. Consider the software tools you use every day that are outside your domain, whether these are ecommerce sites, social media sites, audio books, your car interface, and more. What can you learn from them and apply back to your domain? What can you learn from a MasterClass in chess, poker, cooking, or directing? You and your users will be richly rewarded. 

Oblique Strategies

A common human trait is confirmation bias. We tend to quickly interpret new evidence, whatever it might be, as confirming the status quo or supporting our existing views. This is an efficient and important trait in navigating the world. We can’t look at every stop signal and wonder afresh what red might mean in this context, just because we’ve entered a new intersection. But such habits leak out into our thinking and shut it down. This is harmful for us as designers. It curtails, hampers, and dilutes our thinking until our conclusions are so pat and obvious that we are not prepared to make something new or exciting. It’s painful and awkward to challenge our own thinking. But that act of challenging might in fact be the only thing that can even be called “thinking.” Because we are creatures of habit, we must find ways to challenge ourselves in order to innovate.

One fun easy way I have found to help with this a little bit is called Oblique Strategies. These are a deck of cards, invented in the 1970s by musician Brian Eno and Peter Schmidt. Each card contains a short maxim, suggestion, or remark that can be used to break a deadlock or dilemma you might be having.

The strategies include directives such as these:

• Do something boring.

• Make a sudden, unpredictable, destructive action; incorporate.

• Emphasize differences.

• Work at a different speed.

• Only one element of each kind.

• Would anybody want it?

Picking one of these and using it as a heuristic or a lens through which to view the current aspect of your project can be very illuminating and get you out of a creative jam.

Here’s one way to use them. Each morning, visit the free Oblique Strategies website. Or, if you really like it, you can buy a deck of cards with the strategies on them. Pull a new card and read the strategy, and consider it like a little mentoring guide for your work that day. You can pick one and then state it to the team in your daily standup, or mail them to the team. I’ve used this practice and although it’s by nature impossible to measure the specific impact this has had on the designs, the teams seemed to enjoy it, and I’m sure it caused a few actions or decisions to be reconsidered.

Use Oblique Strategies to challenge your own conventional or default view. You’re activating the synapses of critical thinking and imagination, and that will only help your concepting.

Lateral Thinking and Working with Concepts

You can also take the simple approach we discussed in the Oblique Strategies pattern and extend and deepen it using a technique called lateral thinking. Lateral thinking as an approach to creative thinking and creative problem solving was invented by Edward de Bono in the late 1960s. Dr. de Bono’s PhD was in philosophy and he authored more than 70 books. 

Lateral thinking is concerned with using an indirect, creative approach to problem solving. To do so, you use certain specific techniques to incorporate nonobvious methods of reasoning that help you arrive at conclusions that you might not otherwise get to using linear traditional logic. It’s about how you can search for alternatives without using standard patterns. Traditional logic is concerned with determination of truth value of a given proposition. Lateral thinking, on the other hand, is more concerned with the slippage, reversals, or movement of terms in statements and ideas. As such, it is an important tool for us as semantic designers.

de Bono defines four types of thinking tools to solve problems in an unconventional or indirect manner:

• Idea-generating tools, intended to break thinking patterns that are traditional, routine, or simply represent the status quo

• Focus tools, intended to broaden the horizon as you search for new ideas

• Harvest tools, intended to ensure more value is received from idea generating output

• Treatment tools, intended to prompt consideration of real-world constraints, resources, and support

Dr. de Bono compares traditional vertical thinking with lateral thinking, which we present in Table 11-1.

You can see how well lateral thinking fits into a deconstructive designer’s mindset and work in concepting. The more you design your software in this way, the better it will be.

This is a field of considerable study as well as controversy. But we should illuminate a few of the major tools here that you can incorporate into your concept work:

Challenge idea tool

We often ask the question “why?” to solve a current problem, and this begets Fish Bone Diagrams and root-cause analysis exercises. However, it’s interesting to ask “why?” about something that is not an apparent problem, but a typical state of affairs. To ask why in a nonthreatening way about a current state of affairs or the way something is done can help us innovate and remove headaches and inefficiencies. You can apply it to processes, organizational culture, toolsets, and anything really. For example, in the United States, many states use Daylight Savings Time and roll their clocks forward and back one hour each year. We just do it, and that’s the way it is. By asking “why?” and realizing that the original purpose was to support our agricultural society, which is no longer agricultural, we might stop doing that. Similarly, we might ask why certain conventions are in place for the treatment or expectations of children. It is perhaps shocking to learn that childhood has not always existed, and had to be invented. It is a social construction and not at all “necessary” or even a candidate for the realm of something “true.” In fact the idea of “childhood” has only been with us about 250 years.

Reversal method

A swimmer swimming a lap in a pool will, as soon as they reach the opposite side, kick hard against the wall upon turning around, to move quickly in the opposite direction. Whenever a direction is indicated, an equal and opposite direction is also indicated. If you start in New York and move toward Paris, you’re moving away from Los Angeles. If a person is supposed to obey the government, reverse the relationship and ask what the world would look like if the government had to obey a person or people. Embrace this opposite idea and consider the ramifications in order to put together a new idea. You purposefully and provocatively turn the status quo inside out, upside down, or around to see the world anew.

Provocation

A provocation is a statement that we know is wrong or impossible but is used to create new ideas. This helps you deliberately leave the mainstream in your thinking. Negate what you take for granted about a topic. That negation is your provocation. In Serious Creativity, de Bono gives an example of considering how to handle river pollution. He creates the provocation “the factory is downstream of itself”; this leads to the idea of forcing a factory to take its water input from a point downstream of its output, an idea which later became law in some countries. Other kinds of provocation include wishful thinking (“wouldn’t it be nice if...”), exaggeration (if there is a quantity in your statement, wildly exaggerate it bigger or smaller), reversal (make an opposite statement), escape, and distortion.

Consider the movement in your idea. How can you use a provocation to advance a new idea?

Extract a principle

From this circumstance, provocation, suggestion, or implementation detail, can you define the broader principle that would lead to it? To what seemingly unrelated point can you apply this principle? First try to extract a principle. Then, discard the provocation and work with the concept with the new principle at work.

Random inputs

To escape the mainstream, randomize input that has nothing to do with the topic under discussion into your process and work with it. You start with the focus on your topic at hand. Introduce a random, irrelevant word and then list associations with that word. For each association, use it as a metaphor or descriptor for an idea that might then be related to your original topic and help illuminate an innovative solution or perspective.

Focus on the difference

Highlight and explore the points of difference between the provocation and your idea.

Moment to moment

Imagine or simulate what would happen, what would have to be true, to implement the provocation as is.

Positive aspects

Are there any direct benefits or positive outcomes of the provocation itself? Examine each benefit and see if it could be achieved by practical means.

Special circumstances

Explore for a moment if there are some special circumstances where your provocation might have some immediate use.

Related to the idea of lateral thinking is another book by de Bono’s called Six Thinking Hats. Published in 1985, this book and its techniques were focused on business managers. In the 2000s, it found popularity in the UK government to help spur innovation.

The six hats outlines an exercise that you can do with your team:

White Hat

Concerned with data, definitions, facts, figures; neutral and objective

Red Hat

Intuition, feeling, emotion

Black Hat

Logical, careful and cautious, the “devil’s advocate”

Yellow Hat

Sunny and positive, finds reasons something will work

Green Hat

Growth, creativity, new alternatives, provocations

Blue Hat

Cool, the color of the sky, the meta-hat, organizing, looking at the process

The idea is that these six forces impinge on our thinking and can scramble it. If we instead do a bit of role playing and actively represent the different positions embodied by each hat, we can be clearer in our thinking.

We can’t cover everything about the six hats and lateral thinking presented in de Bono’s work, but I do encourage you to check out his books Lateral Thinking and Six Thinking Hats to learn more about these techniques if you’re interested. I hope you are interested, because lateral thinking represents an excellent way to work with concepts in a challenging, creative manner that will result in your best designs and products.

Code Reviews

I often see code reviews used to police programmers on compliance matters. Code reviews are important, but the code reviewer should not be forced to become the QA department or test compliance with convention guides.

Instead, your code reviews should be about encouraging and deepening your concept, broadening its understanding and application. Code reviews should support the development of the coder through sharing, mentoring, recommendations to best practices resources, and mapping to principles to reinforce them. They help you develop a better bench. You are reducing single points of knowledge across your organization if you can make them a positive and participative experience. You are helping to refactor the design.

The purpose of code reviews is not to put people in their place or to overindulge in nit-picking minutiae. They should elevate, not diminish, the programmer.

As the chief semanticist, designer, or concepter on the technical staff, you should be at least occasionally reviewing the implementation to ensure that your design is being realized properly.

First, be sure your concept is well tested as discussed in the previous section. After code starts hitting the repository, here are a few pointers or guidelines to help you determine the code review process that’s right for you:

• Hopefully your team uses a version control system like Git and a tool like BitBucket, which makes it very easy to for you to view commits and diffs on pull requests, make comments, and treat it as a bit of a conversation. The code can’t be committed until approved by reviewers. This is typically a very good thing. Reviewers must respond quickly to pull requests.

• Encourage developers to notice, use, and take action on the refactorings and recommendations in their IDEs. For example, Eclipse, JetBrains’ IntelliJ Idea, and Microsoft Visual Studio all have capabilities of reading source code and making recommendations. Your developers are doing it wrong if you’re using code reviews to catch possible null pointer exceptions. Use tools for that job and elevate the nature of the code review.

• Use a continuous inspection tool such as SonarQube to improve code quality. It will detect bugs, vulnerabilities, and red flags in the code construction. Have developers run this before pull requests so that your code reviews can be more robust and interesting.

• Review a small batch at a time. If you’re presented with 20 files to review, you will skim and hit only the obvious things. Maybe three classes or a few hundred lines of code is best.

• Make two checklists. There will be things that your developers’ IDEs should just capture. You might be able to tune it to insert your rules to capture low-hanging fruit, using something like Appraise. The second checklist should be things that your developers will commonly violate that the IDE can’t capture as easily. I find these are things like uncommented or poorly commented code, exception handling, proper “discoverable” logging, avoidance of null pointer exceptions, improper use of enums, and so on. These are common things that act as a preliminary review for the developer, to save everyone the brain damage of repeating the same low-level observations at every review.

The manner in which you conduct code reviews should improve your culture. They should encourage transparency, interest in having the best idea win instead of your own idea, conversations about quality so that it stays top of mind, and a brave and open invitation to scrutiny in our work. Code reviews reduce your “truck factor,” so even if you haven’t gone as far as pair programming, you still will get more people with more familiarity with the broader code base.

Of course, if you’re designing the next space shuttle, print out every line of code and review the minutiae in a locked room for weeks before allowing anyone to do anything. For all the rest of us, make it a fun, collaborative learning and team-building experience.

Demos

If a developer on a typical Scrum team finishes his first story in a sprint, he might then wait for a week or 10 days before getting to demo it. Why wait so long to demo code?

As an alternative, when code is done, invite the team to demo it later that day or the next. This aligns your development in an event-driven way, when your story is done. Don’t wait until the end of the sprint if you use those (though Kanban is more consistent). I have used this in the past in a Kanban-like style, and the teams loved it. The sense of progress, competition, drive to complete work, and frequent little public celebrations all conspire to generate a palpable sense of energy, movement, and camaraderie. You can make a party of it. Send an email when a story is done and let everyone gather at the end of the day in a room used for this purpose, put it on a video for the distributed team members, and demo the story. It’s fantastic!

The Operational Scorecard

As deconstructionist designers, we see the whole as well as the parts, and we understand that it’s not only software that are our design candidates. You probably have, or should have, monthly operational meetings. These typically are boring reviews of dead history that cause participants, who are generally forced to be there, to disengage. This in turn makes the meeting worse.

What you want to do instead is design this meeting. As we always do, we begin with one of our key questions: who it is for and what do they want or need to know to make a decision or do something differently?

You can elevate your organization by encouraging your executives and peers to design their meetings. Everything is a potential object of design. And when you take the holistic view, every constituent part becomes improved. As designers, architects, executives, leaders in the business, we will spend a nontrivial portion of the time reviewing performance against our key metrics across the business. That performance will include people, process, and technology and product views. The goal is to understand performance trends, discuss issues we need to address, and get quick updates on improvement efforts underway that will affect our performance.  In your operational meeting, the expectation is that each functional leader will speak to his or her metrics, with questions, issues, suggestions, or concerns being discussed with the broader team.

The goal of the meeting should be:

• Give you and all participants a comprehensive view of the actual progress, the important elements that will give us confidence about how we’re actually doing for our customers.

• Give you a seamless transition to subsequent reporting out to senior executives; the data should cover similar items to minimize repetitive busywork.

• Make a template that is repeatable and easy for your team to update each month.

I urge you to create an operational scorecard template that you can use in the operational meeting. Each meeting simply provides a forum for leaders in each area to present the current state of their organization through this lens.

Your scorecard might include the following as a sample from which you can create a template to share with the leaders to fill out each month in preparation for this meeting:

Roadblocks

Just like in a standup, what remains in your way that might need visibility or executive action?

Risks/mitigations

What problems do you anticipate becoming roadblocks next, and what are you doing to mitigate these?

Major misses

What did we recently mess up? Including this and covering it in a way that is nonjudgmental can help engender transparency and improved collaboration, and makes sure that any relationships that need to be smoothed over are repaired.

Major accomplishments

Who is due some recognition from the leadership team? What went right that we can replicate?

Contracts/budgets

Any deals that need legal or executive review? What seems stuck in procurement or finance or HR or otherwise needs pushing?

“10X" initiatives

What are you doing to “10x” your performance, to compete with the very best in the world at what you do? How are you driving your team to go above and beyond mere maintenance, the status quo?  Instead of just doing our daily jobs, how is your team working to take a big step forward across People/Process/Technology to be the very best in the industry?

Critical skill gaps

For People, what technologies or soft skills do you see that your leaders need to focus on?

MBO/OKR/goal tracking

How is the team progressing against stated goals at the organizational level? Whether you use Management by Business Objective, Objectives and Key Results (OKRs), or any other framework, how close is your team to completing what the leadership team expects?

For each major product by area

State the availability/uptime since last reporting period. How many Sev-1 and Sev-2 production defects does the code base have? Measure mean time to recovery (MTTR) and show that on a graph: we will have failures, the point is to work toward improving how quickly things get noticed, identified, and resolved so that customers are back up.

Cloud spend

What is the Amazon Web Services (AWS) monthly spend (incorporate the reports from CloudHealth, for example, gained through your cloud provider)? What are the recorded security defects reported for each major product as reported by OWASP/Veracode scans? How aligned is the product with the overall enterprise architecture/design and strategy?

For each major initiative

How is your team progressing on an initiative that is not simply specific product creation or maintenance? These might include a modernization effort, cloud migration, database migration effort, datacenter move, disaster recovery (DR) overhaul, a process reengineering effort, and so forth. Report on these right alongside products so that they are measured and visible, too. These might need a different kind of summary with success metrics specifically tailored for each initiative given that they are not product based.

Then, to ensure that you’re taking the comprehensive view and including People as well as Process and Technology, review these items as well:

• Current headcount FTE/contractors

• Current recruiting efforts (number of open positions, offers out, new hires/conversions)

• Terminations/people on Performance Improvement Plans

In your monthly operational review meeting, instead of just having vice presidents attend, you might also consider including folks one level down (the senior directors or directors). This then helps you to build your executive bench. It acts as a kind of training ground for them so that they see what executive meetings are about, how they are run, what the expectations are, and what the conversations are like, and generally helps bring them into the fold for developing their careers. This alone can be a really good motivator. It has the benefit to you as a leader of helping create context, so that you can be more comfortable and confident pushing decisions down to them. With the understanding they’ve gained attending this meeting, they’ll be better equipped to make decisions that are in alignment with your overall strategy.

The Service-Oriented Organization

In this section, we tackle the exciting subject of effective organization design. To do so, we look through two lenses: Conway’s Law and software design principles.

We introduced Conway’s Law earlier in the book. It’s the idea that software designs are copies of the communication structures in an organization. This is often interpreted as a warning that if your organization has lots of committees and lack of clear roles in decision making, you won’t have high cohesion in the software created by the teams in that organization. But we can look at it from the other direction and use this to our advantage as we design our organizational structure. Imagine and refine the set of services you think best define your future state platform. This will include some services as they are now, and some that might not exist yet but represent the direction in which your business is evolving.

To begin, be sure you have a diagram or sketch outlining the set of services your platform provides, grouped together by domain. Consider the following as you sketch this catalog:

• Find a level of abstraction that’s right for several groupings. You don’t want too few or too many groupings within your domain. Fewer than three or four is maybe not granular enough, and more than seven or eight is maybe getting too complicated and thus too difficult to track, manage, and govern. There is no “right” number, but this will rather depend on the size of your company or business unit and where you are in your life cycle.

• The catalog should be balanced so that one grouping is not responsible for 85% of the critical services in the catalog, whereas the others are left anemic with a few random stragglers.

• Consider the items that tend to change at the same time. Group services together that tend to change together. For instance, you probably don’t typically need to change the Profile service when you need to make changes to the Shopping service. But you might need product-related services or distribution-related services to change with them. The point here is to not settle into what seems a “logical” grouping, but rather to consider the efficiency gains you will have if you can limit the number of people helping make a particular decision, attending the meetings, or weighing in on emails. 

• Consider process divisions, such as supply chain, offer management, order management, and fulfillment. Viewing your service catalog groupings through this lens will give you another perspective to consider.

• Consider the specific customer segments you have. Who are the primary customers or users of your services and applications? This will allow you to line up your portfolio in lanes along with your different customers. Serving a B2B customer is different than B2C; serving an enterprise-sized customer is different than an SMB, and so forth.

• Consider the future strategic direction versus the current leaders and what sets of services and applications they own. There might be some left over arrangements from various leaders coming and going that don’t make sense any more. The leaders will be the champions (or detractors) of the required change management to make your service-oriented organization successful. If the people involved do not all have something interesting and important to do while overseeing their domain, they won’t be on board. This is an important element to keep in mind. Sometimes the organization will need a tweak here and there, and sometimes a major overhaul.

Essentially, you are starting with the aforementioned lenses to look at your organizational catalog, and you’ll find the one that alights the best path. By viewing the potential groupings through these different perspectives, you will ultimately arrive at the most effective service catalog groupings to which you can make your future state organizational recommendation. Then, you can socialize this with leaders and work to make the organizational changes accordingly.

As you consider together your service catalog and how you organize it, and how you propose an organization to best support its efficient operation, we can see it as a system. As a system, we can look to the standard tenets of good object-oriented (OO) design to consider how these ideas, usually intended for the realm of software, can also help inspire the design of a great people organization. After all, it’s a system, too. Here are the SOLID principles of OO design:

Single responsibility

Things should have one and only one reason to change. Teams should be organized around the services they offer and are accountable for. Minimize the number of people on the email, at the meeting, and on a call to move more nimbly.

Open-closed

Things should be open for extension, but closed for modification. Therefore, teams should be flexible enough to move where the business heats up. But the teams must be cross-functional enough to have all the expertise they need internally to complete their work. This requires some common technology across teams so that new members can get up to speed quickly. It also means that you don’t modify the teams frequently, moving members around and expecting that developers are somehow the commodity equivalent of interchangeable blade servers. Get the right mix of seniority and expertise on cross-functional teams and then don’t mess with their members very often; let them go through their inevitable Storming/Forming/Norming/Performing phases.

Liskov Substitution Principle

Objects of a derived class should always be substitutable for a parent class. What this means to us is that you need to build your bench so that others can step in for you. If you have a conflict, you want to be sure your team can speak for you with the same message, the same emphasis, and the same principles. This means that as a leader (whether it’s with direct reports or dotted lines as you lead by influence), leaders must build their bench and spend time mentoring others and illustrating the vision, regularly preparing others to step into their place and lead the customer engagement or design meeting without them and still feel confident that it will be done properly.

Interface segregation

A client should never be forced to implement an interface that it doesn’t use. When teams do not create their own interfaces and define the proper way to engage them and the set of inputs and outputs that they generate, it can be awful working with them. To be respectful of other teams, define clearly how they engage you, when they engage you, for what purpose, how long they’ll wait, how they can get permissions or exceptions, and so forth. When teams do not do this, they need to be managed by the team that is depending on them; typically this means engaging with several different members and trying to coordinate them from the outside. It’s just crazy-making. Ideally you would set this up like a version of your own Unix “man” pages within your architecture department first. Do this as practice with your own department, and learn how it feels to create the proper documents to set expectations and then to socialize them. Then branch out to make a recommendation for how others can do this using scalable business machines (which we discuss shortly).

Dependency Inversion Principle

Things must depend on abstractions, not on concretions. The high-level module must not depend on the low-level module. Therefore, hide your organization behind a clear strong interface and contract. Have defined inputs and outputs and do not require other teams to get into your internal business or manage/corral your organization to get their work done.

Now that you have considered your organization through all of the principles and lenses, there is a practical matter. You’re ready to draw up your service-oriented organization in an image. Each organization might look like what is shown in Figure 11-1.

Figure 11-1. The structure of your service-oriented organization representation

Do this for each organization (each VP, probably). You start with the customer, enter the organization at the point of the product VP for that area, and fan into product development VP and assigned architect. These are the named buddies that will work together most closely. They control the portfolio of applications as well as the portfolio of services to govern within their subdomain.

Cross-Functional Teams

Within each of these subdomains, it can really work to your advantage to form your teams with dedicated, full-stack developers on cross-functional teams if you can swing it.

The talent on each team should include people with knowledge of the following:

• Business domain knowledge

• Systems design

• UI/UX

• API design and service creation

• Familiarity with and interest in the overall strategy

• Testing

• Automation

• Data

• Infrastructure, networking, your datacenters

As you populate teams, minimize any cross-team dependencies that threaten the accountability of the outcome. It’s important to persist these teams, keeping them consistent. Don’t frequently swap members from one team to another. They need to go through the “storming/forming/norming/performing” phases. Meddling managers often rob teams of their productivity by moving members around.

With such teams, I have found that you will get more natural leadership, accountability, sense of shared success, free collaboration, curiosity, shared understanding, and habitual reevaluation of quality.

Each cross-functional team works within a single domain. The architects and project managers coordinate across the teams when a complex multi-domain solution is required. This is shown in Figure 11-2.

Figure 11-2. The cross-functional team composition

Within a single domain that corresponds to a named set of salable products, your cross-functional teams should have this composition, or some close approximation. If you do, you will get the most velocity and productivity, the most team accountability and happiness, the best overall throughput for product development, and the most efficient and clear management mechanics. You will get to take best advantage of things like all the pipelines you’re building, reusable libraries, and services and practices like DevOps.

It’s on purpose that I don’t specifically call out “DevOps” developer or something like that here. Although you can (and should, at least for a while) have named developers doing the pipeline and automation work, they’re still developers. Recall that in Agile there is only the role of “developer.”

The Designed Scalable Business Machine

A scalable business machine (SBM) is a representation of the inputs that come into your organization, the outputs you produce, and the principles that underpin the internal processes by which you create those outputs for use by others. The purpose of an SBM is to define your work in a clear process to help set expectations for other organizations with which you work. In a sense, you are defining the interface, the API, for other departments to work with you. It’s important for us to do this because we so often float between product management, strategy, and product development. Defining your own SBM will help you move from the potentially murky realm of adviser into a more clearly effective participatory role, and help make your entire organization more performant and responsive to customers.

The SBM consists of a few main parts:

• Principles

• Inputs

• Processes

• Outputs

• Tools

Principles are propositions that serve as foundational statements for a system of beliefs. Explicitly stating the principles that you want to see enacted in terms of people, process, and technology can help your entire organization be more effective, especially as you undertake large-scale modernization efforts. To create your own set of principles, refer to “Principles” to get some ideas.

Inputs are the raw materials that come into your team. These are the conversations, ideas, documents, and external parameters you use to build your solutions. You don’t define or control them yourself. You might get them directly from customers, the product management team, the strategy team, executives, or a central compliance group.

Processes are the defined activities that you undertake to convert the raw material of inputs into the new, useful outputs. These should be internal to your own team and can be treated like a “black box.” They are the engine working behind your API.

Tools are any helping software programs or other concrete means that you use to produce your concepts and documents.

Outputs are the result of mixing the inputs with your own internal processes using your tools. The outputs should be of clear use to a clear set of customers. Consider who cannot make a good decision or take their next action without having some declaration or direction from you. Then think of how you can formalize that and turn it into a template your team can repeatedly use. Identify what deliverables and metrics matter to the customer. Define metrics incentives internally to drive toward great customer outcomes.

Figure 11-3 shows a sample template that you can use to define your own SBM.

Figure 11-3. A sample scalable business machine

The principles are not listed on the template, but they could be. Here are some examples of principles that you might adopt and adapt:

• Primacy of principles.

• Solutions must first comply with laws, regulations, and standards.

• Nonfunctional requirements must be considered on equal footing alongside functional requirements.

• Data is an asset, shared, and accessible, and requires stewardship.

• Solutions must be service oriented, and designed in accordance with the service design framework.

• Development work must be aligned with the stated architectural strategy.

• Solutions must be globally deployable.

• Solutions must be cloud native or cloud ready.

• The organizational structure must be aligned with system governance.

The goal of creating an SBM is to maximize efficiency, maximize speed to market, scale the business better, delight customers, win back customer trust, increase employee engagement, and so forth. These are the typical goals of any business. Orient your SBM around these goals depending on your current needs.

This book’s companion volume, Technology Strategy Patterns, elaborates on the idea of the SBM more thoroughly. I encourage you to do this for your own architecture-design department. You will likely have different principles, tools, and inputs, and that’s a good thing. Introduce the SBM idea to your team and have a workshop to construct your own diagram. This will help you to create a contract-oriented interface with other organizations and set expectations properly.

If the effort proves effective for your own department, I encourage you to lead similar workshops for other departments in your organization. Of course, if you decide to do that, you must first get the understanding and approval of the senior leader in that area, and work with that person.

Managing Modernization as a Program

There are large initiatives that architects might be invited to participate in or assigned to run. The effective enterprise architect will not try to execute these from the bottom up, or as small, local, individual, unrelated projects. Instead, view them as a holistic program that requires management from a senior program manager, as shown in Table 11-3. You can apply a mindset here to “think globally, act locally.”

Writing the code is maybe 15% of a software project, and less if the project is a digital transformation effort. They are change management efforts. Because this is one of the top three reasons that projects fail, we address it in our method.

As an architect or systems designer, you are not likely to be expected to be in charge of these areas. But you can have a tremendous impact on the overall success of the program. Seeing your large-scale effort as requiring true program management and change management is essential to its overall success. If your PMO is mature, well-staffed, and powerful, architecture might be more on the production and participation end of such programmatic management. Either way, you can play a central role in helping to bring these proper activities, business guardrails, and processes to the fore. As a deconstructive designer, your comprehensive view of the semantic field that includes promulgating the need for these activities, and for properly representing your team’s perspective in these areas, will help to make your programs a success.

Change Management

Change management is the active, programmatic management and leadership of an organization through some large change. Is your organization going through any of the following efforts?

• Large digital transformation programs

• Modernization programs

• Service portfolio management efforts

• Mission-critical systems overhaul

• Datacenter migrations

• The creation of a platform

• Mergers and acquisitions

• Organizational restructuring

• Large-scale business process reengineering

Any of these should be considered change-management efforts. They will result in the redefinition and reallocation of funds and other resources, changing processes, retraining, and more. They will create the need for considerable communication and nurturing of the staff and other stakeholders throughout the process. They will need programmatic oversight and architectural involvement.

Typically, an executive will be the sponsor for such efforts and appoint a leader to act as the named accountable party. As an architect, this might be you. Even if a different leader is accountable, architecture will likely be a responsible or recommending party for one or more of the activities in the overall change-management effort. The effective enterprise architect can serve as the locus of many interrelated activities across a variety of departments, helping guide the effort to success.

Figure 11-4 presents my change management framework, which you can use or adapt for your own needs.

Figure 11-4. The change management framework

Depending on the nature of the change management program, you might have more or less need for each of these activities.

Analogous to these four phases of change management illustrated in Figure 11-4 are four phases of a project or development method. Whatever your software development methodology is, you will go through the following phases:

Define

Create the vision, goals, parameters, and definition of successful completion for the effort.

Design

Create a set of concepts from which you derive systems: new business processes, new data flows, new software, new infrastructure.

Develop

Do the work to realize the designed system.

Deliver

Complete the transfer of the work product to the customer.

If you follow more of a waterfall process, these phases can be very sharply delineated with phase gates. If you follow more of a Scrum or Kanban method, they might be more iterative or less formally defined. But you’ll still touch on each of these concerns for at least some time. The point is to be consciously aware of them and define the expectations for your stakeholders. Moreover, it will help us to remember the many diverse stakeholders in a program and recognize their different needs and plan accordingly. Helping to set good expectations is one of the best ways for you to help your organization overall.

Figure 11-5 illustrates the activities and documents you generate in each of these phases. As an effective enterprise architect, you can help to guide the product management, program management, legal, HR, development, and other teams through these steps as necessary.

Figure 11-5. The change management activities in each phase

Change management is a huge field of study on its own. Your company might employ legions of Deloitte or Accenture consultants for millions of dollars to help define and lead these efforts. For the rest of us, the framework provided here should give you a good starting point, set of reminders, checklist suggestions, and other tools that you can adopt and adapt for your own needs.

Governance

To advance your service catalog with clarity, purpose, and alignment with the overall vision, create a governance committee. Its working members should include architects/designers and development leaders.

Service Design Checklist

Your governance should exist as a structured organizational body. This is a cross-functional committee of architect/designers, development leaders, and product leaders who can work at a high level with a view across the entire portfolio of services. This ensures that overall what your teams are developing is actually accruing toward the vision for your platform or general product strategy.

But you must also have a practical means of checking the work at the local level. As each individual service is developed, you want to make sure they are developed in accordance with the many nonfunctional requirements that operate alongside the functional requirements. For this purpose, it’s helpful to have a checklist that ensures proper service design.

Here is a sample list that you can adopt and modify for your own purposes.

Further Reading on Organizational Design

• Aronowitz, Steven, et al. “Getting organizational redesign right”, McKinsey Quarterly (June 2015).

• Davis, Stanley M. and Paul R. Lawrence. “Problems of Matrix Organizations”, Harvard Business Review (May 1978).

• Henshall, Adam. “How 4 Top Startups are Reinventing Organizational Structure”, Process Street.

• Morgan, Jacob. “The 5 Types Of Organizational Structures: Part 1, The Hierarchy”, Forbes.com.

• Neilson, Gary L., et al. “10 Principles of Organization Design”, strategy + business (Summer 2015).

• Peters, Tom. “Beyond the matrix organization”, McKinsey Quarterly (September 1979).

• Sisney, Lex. “Rethinking Product Management: How to Get from Start-up to Scale-up”, Organizational Physics.

• Sisney, Lex. “Predictable Revenue: How to Structure the Customer Success Role”, Organizational Physics.

• Stuckenbruck, Linn C. “The matrix organization”, Project Management Quarterly (September 1979).

• Tollman, Peter, et al. “A New Approach to Organization Design”, BCG.

• Whalley, Brian. “SaaS Company Structure: Learning From 13 More Companies”, InsightSquared.