The answer, of course, is organizations usually are not designed from the ground up in such a manner. They evolve over time, focusing on immediate business needs and addressing specific, narrowly scoped problems. The goal may be business modularity, but all too often the actual actions continue to support fragmented architecture.
I once worked for an organization that had twenty four ERP systems. Twenty four. Nobody designed that, nobody wanted that, but there we were. They all came by mergers and acquisitions of companies that themselves recently merged with or acquired other companies. The technologies involved ranged from VMS systems running on (proprietary, or course!) DEC hardware to a version of Apple's FileMaker that was released in 1994 and everything in between.
"In most cases, systems built to achieve immediate business needs have become expensive, redundant, and difficult to maintain." (Ross 93)
Needless to say, it was a challenging environment to support. And great progress made to achieve the lofty goal of "One ERP." One by one, these older systems were sunset, their data migrated over to the organization's architecture ERP solution, but the biggest error was that many of the older systems were allowed to linger, in read only mode.. They were all running on horribly out of lease/owned hardware and nothing had official support, so there was no cost. What wast the harm, right?
The trouble was, the user base didn't stop using them. Any sort of change is difficult and many many users simply refused to use the designated tool and continued to leverage the legacy systems. And man, were these folks dedicated. Unofficial 3rd party applications were brought in to support the older environments. There were a few cases were some code was hacked together. And when this illicit tech stack would break, the losses in revenue could be measured in the millions. This was allowed to continue by executive leadership for far too long, squeaky wheels get the grease I guess. It was only Windows XP going EOL and the mass exodus to Windows 7 that came after which finally toppled the house of cards, since the clients for many of these systems would no longer function.
I think the lesson here, is that EA needs to not just be about the management of technology...it must also be about managing people. "If you build it, they will come" is only is guaranteed to work for Kevin Costner.
Ben,
ReplyDeleteAllowing legacy systems to stick around promote undesirable user behavior as old habits die hard. Your statement was telling when you stated executive leadership allowed this to continue for too long.
Ross et al’s text reading for this week which takes us through the growing pains an enterprise has to overcome maturing from stage 1 to stage 4 of EA maturity has made an observation about lessons to be learnt from high performing companies which have achieved high strategic effectiveness. That takeaway is greater senior management involvement in enterprise architecture issues. Perhaps leadership’s active role would have helped your organization cash in on the benefits of the new systems earlier.
I found this week’s reading to be interesting and informative and thoroughly enjoyed reading the same.
Twenty-four different ERP systems? And we wonder why people don't see the value in this stuff - of course they won't when they're wasting that many resources on redundant functions.
ReplyDeleteI agree that EA isn't really a company's primary goal, either. If we think about it, when a company is formed, you first have to manage your cash flow. But this changes when you have sustainable capital; you can more readily focus on efficiency and process improvement through EA; this is where most companies get stuck, in my opinion. And by virtue of this business model, you have multiple inefficient systems when the companies grow. It really is the ultimate catch 22 - should we focus on our processes and then grow the company, or vice versa?
I can relate to the difficulty of having obsolete systems exist alongside their replacements. My organization experienced this when working to replace reporting systems for sales data. Two solutions existed simultaneously, with the second solution intended to be a Kimball-methodology BI replacement of the first. The second solution wasn't well architected and competing requirements from the business. The business frequently reported discrepancies between the two solutions, which led to the second solution never being accepted or completed.
ReplyDeleteWe decided to start over with an Immon-methodology solution, architected with a data warehouse and multiple data marts. Once the solution was proven and released, the next phase of the project was to move users off the previous two solutions and eliminate them from use. After designing some transitional reports, we were able to remove the legacy systems from service and move forward with a single source of truth.
The approach has served us well in later projects. Where possible, offer a soft release where both systems can be used in parallel. Once the new solution has been proven, negotiate a cutoff date with the business after which the obsolete solution will be taken out of service. One could think that merely designating the obsolete solution as unsupported would suffice, but try telling that to a VP when the unsupported solution is still being used for a key business process and it breaks unexpectedly.