Warning: Use of undefined constant user_level - assumed 'user_level' (this will throw an Error in a future version of PHP) in /home/commons/public_html/wp-content/plugins/ultimate-google-analytics/ultimate_ga.php on line 524
I’m struck by both the simplicity of why organizations might be designed in a modular manner for the production of modular products and the immense real world challenges of building modular systems rather than interconnected systems. Reading Langlois, I cannot help but think of how my employer Cognizant found itself torn between these two approaches on my project this past summer.
The 40,000 foot long-term view of the client’s needs was to move from a pre-digital operating model, to an industry leading company optimizing modern technology and data to excel in the healthcare insurance industry. As a health insurance company many distinct groups of internal and external users need to access the same pool of data for a variety of purposes (claims, sales, benefits, provider access, etc.). In a sense, the overall company forms the architecture of the “system.” That company level “system” of teams is supported by distinct system applications that can be seen as the modules of the overall system – Salesforce Sales Cloud supports the Sales team, Salesforce Service Cloud supports call center support services, a system called TranZform supports all of the external user needs to access information (contracting, bills, claims, etc.), and on. The engagement involved three major system environments – Salesforce, Oracle, and Tranzform – with four additional industry specific systems.
With all of the subsystems under these the total architecture was comprised of 16 modules with varying levels of integration, a singular system served to provide the communications interface between these modules, and a need to adhere to internal performance standards as well as government regulated handling of personal health information. Understandably, this is the largest and most ambitious engagement of its kind ever undertaken.
So how to tackle such a complex system? Well Cognizant has specialist teams for each of the 16 module level systems. These teams use approach product development from a largely Agile Methodology, chunking their systems into bite sized modules of work, as has become the tech industry standard. Over the years the organization had been built up to anticipate the challenges of ensuring that each Salesforce based module would successfully integrate with the other Salesforce modules at the final go live date. This was known and this worked. However, even a large, multi-module, Salesforce implementation strains the ability of individuals involved to keep track of the interoperability of the systems and the big picture impacts of small design decisions. Managing both that level of system interaction as well as the larger, cross-environment interactions, led to significant concerns about usability at go-live. Even while one module may be complete, it is useless without the full operability and communication of many other modules. Continuing to design in an Agile manner by module from the bottom up runs the risk of significant failure in the end product. This was an issue my team worked to bring to the forefront of leadership, asking that we pause and reassess whether the ideal of modularity was truly feasible.
My question still though, is was this project always too big to succeed? Since no one system could fulfill the needs of the company architecture, modularity will always be the answer. Given that constraint, how does a team of designers and strategists go about “minimizing the interdependencies” of such a complex system? It seems to me that a clear set of communication standards, starting with identifying and mapping these interdependencies, must form the foundation from which the modules can be built.
Richard N. Langlois, “Modularity in Technology and Organization.” Journal of Economic Behavior & Organization 49, no. 1 (September 2002): 19-37.