At the time of writing, Apple Inc. is the largest corporation in the world as measured by market cap. The company itself, started life in the latter part of the mid-1970s, and over the course of time, has transitioned through a myriad of substantial changes. Ostensibly, these changes have been sufficiently distinguishable such that the Apple of today isn’t really the Apple of yesteryear. But, without attempting to make any type of bold and brash prediction, the Apple of today isn’t likely to be the Apple of tomorrow.
Neal Fishman and Paul Homan, CTO, IBM
Neal and Paul will be speaking at the Virtual Enterprise Architecture & Business Process Management Conference Europe 11-14 October 2021 on the subject, Architectural Thinking: Preparing for Uncertainty
We can readily observe that—the original founders: gone. The original company name: gone. The original location: gone. The original product line: gone. The original logo: gone. The location of manufacturing: shifted. The tax (financial) practices employed: shifted. The list could go on.
Apple is clearly a company that is thriving in this perpetual state of flux. As an outsider looking in, we might assert that it enjoys a controlled state of flux! That for Apple, as an innovating and pioneering industrial explorer, flux control is a tool to determine its destiny – helping to manage their sensitivity to change and their preparedness.
Now, from time to time, Apple has been cited for lagging with features for specific product lines and has had to play catchup. For example, the speed by which Apple incorporated 5G into a commercially available iPhone, or how quickly Apple increased the density of pixels on a monitor or screen to match or exceed its competitors. However, the type of change that we are driving at involves bigger and broader brushstrokes of change beyond just product innovation. As an industrial explorer, Apple has the appearance of a proactive culture of innovation through all of its organizational viewpoints rather than that of a reactive culture that is seen through a product lens.
So, what of Apple’s tomorrow? Will they release their anticipated electric vehicle? Who knows? But, the one thing that is for sure is that things at Apple (and by extension, any other organization that may wish to be stay relevant) will be revamped, revised, shifted, and otherwise changed compared to what exists today in order to remain essential to their chosen markets.
So, what exactly is this change? As we’re not insiders, it’s hard to say—we are as it were, uncertain! But, if we look at Apple’s “as-is” current (and knowable) state as well as Apple’s past, including its various “what-was” states, we can frame various parameters of its “to-be” or future state. Thus, we can logically start to rationalize about uncertainty – and develop our own “flux control methods.”
In the field of enterprise architecture, how we choose to deal with uncertainty has a direct impact on what it is we ultimately build. As architects, uncertainty or jettisoning uncertainty for a stringent focus on certainty, can affect how we approach the creation of a particular architecture or design.
While a change in the business is often something that is viewed as a positive, change in IT is typically a negative. Having to change a system to accommodate a new need is a burden and a drain on any IT department. Being forced to open up a codebase to revise a piece of software to meet a particular need that has been announced (i.e., a new or revised requirement) takes time, costs money, and contains elements of risk. In our (IT) industry, having to periodically revise code is blindly accepted as a given norm. In fact, if you add documentation to the code, you can start to layout a best practice about how to make code even easier to revise. Once something is a declared best practice, it makes the practice prudent.
If the only practical option is to make a code change every time there is a new requirement, then we must declare that our fundamental architectures and designs (if they exist) are fragile and brittle. There has to be some line of thinking that we can bring to the table to help us address and prepare for an uncertain future without always having to fall back on using code revisions as a primary vehicle of remediation—even if we have stella CI/CD processes that are automated to help expedite a sprint.
Today, each of us is likely to have enough history about our respective organizations that we can identify what a normative type of change looks like (even if any instance of change is drastically different from a prior change—it’s potentially, normal for the organization). How our organizations buy and absorb other companies into our own, how we divest lines of business, how we react to competitors, how we enter new markets, how we go about exiting a market, how we expand a revenue base, how the corporate culture tolerates or encourages certain behaviors, and so on.
We can use all of our acquired knowledge to help with anticipating a type of change that may occur. As architects, can we then turnaround and use this knowledge to influence our how we pull together a solution: this is broadly referred to as architectural thinking. Can we establish an enterprise architecture, or do we use micro architectures that are tied to a project scope, a product line, a business unit? Is an enterprise architecture a conglomeration of architectures or something more singular that serves discrete needs of each evolving business?
Invariably, your gut reaction might push back and say that our architecture scales, provides for resiliency, addresses throughput performance, and so on; so, of course, it handles uncertainty. While this handling of uncertainty is likely to be true, upon closer examination, we might just be showcasing our ability to accommodate uncertainty by focusing exclusively on a set of non-functional requirements.
So, let us redirect the nature of thinking about uncertainty by shifting the focus squarely on the functional requirements of an organization. If we only think about scaling our solutions from a functional requirement perspective for a moment, we might recognize that the outdated assumption that simply “adding squads or sprints” to help us scale out has often been observed to fail once the size of what we are facing in the application functionality, data and business layers become much bigger than a single “roomful” of people can hold in their heads at any one time. Clearly, scaling can introduce uncertainty in many ways.
Addressing uncertainty when it comes to a future set of features and functions will not be an exact science. But, considering future needs before they are known or formalized can help us rationalize how we approach our craft as architects. By addressing uncertainty, we can train ourselves to think abstractly. Ideally, it would be nice if we can steer our creations to be conducive to adaption over the use of refactoring and brute force changes. If we can learn to shift our orientation of thinking, we can begin to shift how well, we in IT, are aligned with the business, and how well our IT departments can reduce the time gap to regain alignment every time a new functional requirement surfaces.
Messrs Fishman and Homan are both CTOs within their relevant geographies for IBM (U.S.A. and U.K. respectively). They are both IBM Distinguished Engineers and Open Group Distinguished Architects. Both have served as board members for recognized international user groups. Another aspect that they have in common is the authoring books/blogs and the practice of enterprise architecture. One area that is distinctly different (semantically, at least) is the primary industry upon which they practice their craft and art!
Copyright Neal Fishman and Paul Homan, CTO, IBM
 Industrial explorer is a term that harkens back to a 1929 book by Maurice Holland.