Who Needs Architects? – Monoliths as Systems of Stuff

Platypus

In my experience, IT is not a “one size fits all” operation. In both their latest two-speed vision and their older three-speed one, Gartner’s opinion is the same – there is no one process that works for every system across the enterprise (for what it’s worth, I agree with Simon Wardley that Bimodal IT is still too restrictive and three modes comes closer to reflecting the types of systems in use). Process and governance that is appropriate to one system may be too strict for another and too loose for a third. In this light, attempting to find one compromise ensures that all are poorly served. Consequently, more than one mode of governance just makes sense.

The problem is more complex, however, than just picking trimodal or bimodal and dividing applications up according to whether they are systems of record, systems of differentiation, or systems of innovation (or digital versus traditional). Just as “accidental architecture” can result in a “Big Ball of Mud” at the application level, it can also do so in terms of enterprise IT architecture. Monoliths that have grown organically may cross boundaries of the multimodal framework taxonomy, essentially becoming incoherent systems of “stuff”. This complicates their assignment to a process that fits their nature. When the application fits more than one category, do you force it into the more restrictive category or the least restrictive? No matter which way you choose, the answer will be problematic.

Given the fractal nature of IT, it should not be a surprise that design decisions made at the level of individual applications can bubble up to affect the IT architecture of the enterprise as a whole. Separation of concerns (logical) and modularity (physical) remain important from the lowest level to the top. Without a strategic direction, tactical excellence can lead to waste from lack of focus.

Monolithic architectures trade simplicity for modularity at the application architecture level, which may be a valid trade at that level. If, however, a monolith crosses framework category boundaries, then major architectural refactoring may be required to avoid making ugly compromises. Separation of concerns within a monolith can ease the pain of this kind of refactoring, but avoidance of the need for refactoring is even more painless. Paying attention to cohesion across all levels of granularity and designing with extra-application as well as intra-application concerns in mind is necessary to achieve this avoidance.

Knowing the issues and being able to say why you made the choices you did is key.

Advertisements

Form Follows Function on SPaMCAST 323

SPaMCAST logo

I’m back with another appearance on Tom Cagley’s Software Process and Measurement (SPaMCast) podcast.

SPaMCast 323 features Tom’s “Five Factors Leading to Failing With Agile”, my “Microservice Principles and Enterprise IT Architecture” and an installment of Jo Ann Sweeny’s column, “Explaining Communication”.

Enjoy!

Microservice Principles and Enterprise IT Architecture

Julia Set Fractal

Ruth Malan is fond of noting that “design is fractal”. In a comment on her post “We Just Stopped Talking About Design”, she observed:

We need to get beyond thinking of design as just a do once, up-front sort of thing. If we re-orient to design as something we do at different levels (strategic, system-in-context, system, elements and mechanisms, algorithms, …), at different times (including early), and iteratively and throughout the development and evolution of systems, then we open up the option that we (can and should) design in different media.

This fractal nature is illustrated by the fact that software systems and systems of systems belonging to an organization exist within an ecosystem dominated by that organization which is itself a system of systems of the social kind operating within a larger ecosystem (i.e. the enterprise). Just as structure follows strategy then becomes a constraint on strategy going forward, the architectures of the systems that make up the IT architecture of the enterprise influence its character (for good or bad) and vice versa. Likewise, the IT architecture of the enterprise and the architecture of the enterprise itself are mutually influencing. Ruth again:

Of course, I don’t mean we design the (entire business) ecosystem…We can, though, design interventions in the ecosystem, to shift value flows and support the value network. You know, like supporting the development community that will build apps on your platform with tooling and APIs, or creating relationships with content providers, that sort of thing. And more.

So what does any of this have to do with the principles behind the microservice architectural style?

Separation of concerns, modularity, scalability, DRY-ness, high-cohesion, low coupling, etc. are all recognized virtues at the application architecture level. As we move into the levels of solution architecture and enterprise IT architecture (EITA), these qualities, in my opinion, remain valuable. Many of the attributes the microservice style embody these qualities. In particular, componentization at the application level (i.e. systems as components in a system of systems) and focus on a particular business capability both enhance agility at the solution architecture and EITA levels of abstraction.

Conventionally, the opposite of a microservice has been termed a “monolith” when discussing microservice architecture. Robert Annett, in “What is a Monolith?”, takes an expansive view of the term, listing three ways in which an application’s architecture can be monolithic. He notes that the term need not be pejorative. Chris Carroll, in “A Single Deployment Target is not a Monolith”, prefers the traditional definition, an application suffering from insufficient modularity. He notes that an application whose components run in process on the same machine can be loosely coupled and modular. This holds true when considering the application’s architecture, but begins to falter when considering the architecture of a solution and more so at the EITA level.

In my opinion, applications that encompass multiple business capabilities, even when well designed internally, can be described as monolithic at higher levels of abstraction. This need not be considered a bad thing; where those multiple capabilities are organizationally cohesive, more granular componentization may not pass a cost/benefit analysis. However, where the capabilities are functionally disparate, the potential for redundancy in function, lack of organizational alignment, process mismatch, and data integrity issues all become significant. In a previous post, “Making and Taming Monoliths”, I presented a hypothetical solution architecture illustrating most of these issues. This was coupled with an example of how that could be remedied in an incremental manner (it should be noted that the taming of a solution architecture monolith is most likely to succeed where the individual applications are internally well modularized).

Higher level modularity and DRY-ness enhance both solution architecture and EITA. This applies in terms of code:

This also applies in terms of data:

Modularity at the level of solution architecture and EITA is also important in terms of process. Whether the model is Bi-Modal IT or Pace-Layered, it is becoming more and more apparent that no one process will fit the entire enterprise (and for what it’s worth, I agree with Simon Wardley that Bi-Model is a mode short). Having disparate business capabilities reside within the same application increases the risk of collisions where the process used is inappropriate to the domain. When dealing with Conway’s Law, it’s useful to remember “I Fought the Law, and the Law Won”.

Even without adopting a pure microservice architecture for any application, adopting some of the principles behind the style can be useful. Reducing redundant code and data reduces risk and allows teams to concentrate on the core capabilities of their application. Modular solution and enterprise IT architectures have more flexibility in terms of deployment, release schedules, and process. Keeping applications tightly focused on business capabilities allows you to use Conway’s Law to your advantage. Not every organization is a Netflix, but you may be able to profit by their example.

Application Lifecycle Management Revisited

Although I just touched on the subject of ALM two weeks ago, an article published last week in Dr. Dobb’s journal highlighted an important aspect that I had not covered. “Pace-Layered Application Strategies, Fact or Fiction?” discusses Gartner’s Pace-Layered Application Strategy, which is described as a ” methodology for categorizing applications and developing a differentiated management and governance process that reflects how they are used and their rate of change”.

Gartner identifies three classes of application in order to align governance with business priorities:

Systems of Record — Established packaged applications or legacy home-grown systems that support core transaction processing and manage the organization’s critical master data. The rate of change is low, because the processes are well-established, common to most organizations, and often are subject to regulatory requirements.
Systems of Differentiation — Applications that enable unique company processes or industry-specific capabilities. They have a medium lifecycle (one to three years), but need to be reconfigured frequently to accommodate changing business practices or customer requirements.
Systems of Innovation — New applications that are built on an ad hoc basis to address new business requirements or opportunities. These are typically short lifecycle projects (zero to 12 months) using departmental or outside resources and consumer-grade technologies.

I can argue with the name System of Record as that term already has a specific meaning unrelated to their usage. For example, a System of Differentiation can be a system of record in the commonly accepted sense. Likewise, I believe the range for the medium lifecycle is too long. In my experience, Systems of Differentiation can have release cycles as low as three months. Aside from those minor issues, the underlying message is solid.

The nature of these different types of applications clearly precludes a “one size fits all” approach. Attempting to govern all systems with too strict a process will stifle innovation. By the same token, if a publicly traded corporation’s financial systems are managed (mis-managed) in an ad hoc manner, the fallout will be significant. As with any process, selecting the right tool for the job at hand is key.