This (and last) week’s reading material about Application Architecture have been very enlightening and hit close to home for me, as much of my recent career has been spent either working as a Solution Architect myself, or alongside others with this title that focus on planning and implementation of enterprise applications. In my world, this work is done in the context of Product Lifecycle Management (PLM) which differs in scope and mission from ERP which I will explain below, but for the sake of conversation can be considered similar. Notably, from 2019 until last year I was a technical lead on a project with a team of “architects” under my direction. During that experience, I began to notice inconsistencies in the way this role is considered, and what application architecture is.
While going through the assigned readings, I happened to see a recommended article on Gartner titled, Find Your True Meaning of ‘Architecture’ to Succeed with DevOps (Mann, 2019). In it, the author explains that the meaning of “architecture” has become distorted over time. This has led to an all too familiar condition that I often encounter in my line of work—monolith syndrome. This is a state in which the composition of a thing which is multifaceted, multilayered, complex, and nuanced, is ignored in favor of an oversimplified and singular meaning. I was really intrigued to see this term used in another Garter article this week, The Future of ERP Is Composable (Faith, Torii, & Schenck, 2020).
I get what the authors are saying in the “composable” argument, and I think I like it but honestly don’t know yet. From what I read, it is being proposed as the alternative to “monolithic”. Although it’s not practical to fully represent all levels of abstraction all the time of a particular thing, that doesn’t mean that these abstractions don’t exist, and for good reason. If they are not acknowledged, this makes it very difficult to have productive conversations, much less perform useful and accurate planning that involves said thing. Along with this, I’m a bit unsettled to read that current thought leadership around ERP is saying to avoid single source of truth. This seems to be in direct conflict with a major PLM principle, but I think the context differs.
PLM is a scope of responsibilities and methods, and resultant applications, that was born from requirements in engineering and manufacturing around vaulting and change management of information as it transitioned from paper drafting sources to digital authoring sources. This evolved in the 80s and 90s. But the precursor for PLM really dates back to the 50s with Configuration Management. Some time spent on Google will reveal the history of this discipline, but long story short it came out of the Department of Defense as products like missiles and aircraft became increasingly more complex. Simply put, the information required for engineered products is well beyond the ability of average business people and systems to readily process. Over the years, some PLM systems have evolved into their own platforms in order to solve some of the problems brought about by these complex requirements and scope. Within this platform context, they are indeed “composable”. But at the EA level, in relation to ERP, they are obfuscated within the PLM platform and therefore collectively look like a monolith.
The idea that these evolutionary PLM systems can be deconstructed into a compatible, composable existence within the ERP landscape is not going to happen given their dissimilarity in the types of data they are designed for…modern era PLM is model based and ERP is document based. The notion that ERP sits in the enterprise as a primary hub of information flow is historically challenged by PLM, and even more so in a model-based engineering and manufacturing environment. There really is no way for ERP systems to “eat an elephant” that they were not fundamentally designed for. So, in this regard if the context of composable ERP means that the change occurs on their side with the traditional monolith becoming more integration friendly, this may be really great news for PLM folks like me.
I was pleased to see the following graphic in the True Meaning article:
I think this is a good way of first revealing the problem with monolith syndrome—what is being referred to as a singular item (thereby requiring no structure) is actually a rather unstructured and disordered mess of concepts. Adding structure and order reveals the levels of abstraction, scope, overlaps, and gaps that directly relate not only to the architecture elements themselves, but also informs the roles and responsibilities of the human resources expected to design, maintain, and improve them. Given the inherit challenges of alignment between historically disparate groups of people (development, operations, engineering, IT), it seems to me that sharing a common definition of essential concepts is an essential foundation on which to build success. And it no doubt would help in the case of PLM and ERP to realize a more compatible and mutually beneficial composition.