Monolithic Applications and Enterprise Gravel

Pebbles

It’s been almost a year since I’ve written anything about microservices, and while a lot has been said on that subject, it’s one I still monitor to see what new pops up. The opening of a blog post that I read last week caught my attention:

Coined by Melvin Conway in 1968, Conway’s Law states: “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” In software development terms, Conway’s Law suggests that a given team will build apps that mirror the team’s organizational structure. Siloed functional teams produce siloed application architectures.

The result is a monolith: A massive application whose functionality is crammed into a few crowded parts. Scaling a simple pattern to the enterprise level often results in a monolith.

None of this is wrong, per se, but in reading it, one could come to a wrong conclusion. Siloed functional teams (particularly where the culture of the organization encourages siloed business units) produce siloed application architectures that are most likely monoliths. From an enterprise IT architecture aspect, though, the result is not monolithic. Googling the definition of “monolithic”, we get this:

mon·o·lith·ic
ˌmänəˈliTHik/
adjective
  1. formed of a single large block of stone.
  2. (of an organization or system) large, powerful, and intractably indivisible and uniform.
    “rejecting any move toward a monolithic European superstate”
    synonyms: inflexible, rigid, unbending, unchanging, fossilized
    “a monolithic organization”

Rather than “a single large block of stone”, we get gravel. The architecture of the enterprise’s IT isn’t “large, powerful, and intractably indivisible and uniform”. It may well be large, but its power in relation to its size will be lacking. Too much effort is wasted reinventing wheels and maintaining redundant data (most likely with no real sense of which set of data is authoritative). Likewise, while “intractably indivisible” isn’t a virtue, being intractable while also lacking cohesion is worse. Such an IT architecture is a foundation built on shifting sand. Lastly, whether the EITA is uniform or not (and I would give good odds that it’s not), is irrelevant given the other negative aspects. Under the circumstances, worrying about uniformity would be like worrying about whether the superstructure of the Titanic had a fresh paint job.

Does this mean that microservices are the answer to having an effective EITA? Hardly.

There are prerequisites for being able to support a microservice architecture; table stakes, if you will. However, the service-oriented mindset can be of value whether it’s applied as far down as the intra-application level (i.e. microservices – it is an application architecture pattern) or inter-application (the more traditional SOA). Where the line is drawn depends on the context of the application(s) and their ecosystem. What can be afforded and supported are critical aspects of the equation at all levels.

What is necessary for an effective EITA is a full-stack approach. Governance and data architecture in particular are important aspects to consider. The goal is consistent, intentional alignment across all levels (enterprise, EITA, solution, and application), promoting a cohesive architecture throughout, not a top-down dictatorship.

Large edifices that last are built from smaller pieces that fit together on purpose.

Advertisements

4 thoughts on “Monolithic Applications and Enterprise Gravel

  1. I like the distinction you draw between MSA and “traditional” SOA (intra vs. inter) but I’m wondering how you delineate an “application” in drawing that distinction? Service-based functionality implies that what we used to call applications sort of fade away in favour of services provided by/consumed by business capabilities. Do you see an application being something like a “container of services” (I know, overloaded-term-alert!) that is provided by one or more capabilities?

    Like

    • I think I might have got a clue in your post https://genehughson.wordpress.com/2014/11/24/microservice-principles-and-enterprise-it-architecture/ where you talk about a better definition of what is often called a monolith – something which supports disparate business capabilities. The “container of services” I clumsily raised in the previous comment is a grouping of 1 to n capabilities with a high degree of process and data affinity (and other criteria, but they’ll do for now).

      Like

      • I wouldn’t call the term “container of services” clumsy…I think it’s actually a pretty good one.

        In my opinion, the defining characteristic of the intra/inter difference is one of being able to stand alone. A microservice architecture would be built with each bounded context as a service where a traditional SOA application would serve some full business purpose and incidentally expose services that could be used by other applications. It’s somewhat fuzzy, but I hope that helps.

        Like

      • Well, I see SOA services (at their highest level) as being stateless, with those services orchestrated by process steps (which keep state) at *their* lowest level. Then the pattern repeats at lower and lower levels of detail (there’s that fractal thing again 🙂 ).

        Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s