Blog 02: Bridging the Gap

While I was reading chapter 4 of the Ross et al text, I was struck by how obvious it all was.  Why do companies even both with "silos" when the prospect of shared services demonstrates so much potential value?

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.

Blog 01: It's a Struggle...

I want to preface my thoughts here first by saying that all of my professional experience is from the IT side of the house and as such, I am sure I harbor some bias on where exactly IT belongs within an organization.  That said:

In almost every organization I've been a part of, there has been an ambivalent relationship between IT and the "business."

The business side believes that IT is solely a support function, a cost center, and above all else, an impediment to getting things done by inflexibly wielding their arbitrary process and rules and the answer to every request is always "no."  Even worse, IT loves to implement technology for technology's sake, i.e. attempting to fix processes that are not broken or trying to force business processes to be run on non-ideal technologies.

The IT side believes, above all else, they are underfunded and unappreciated, due to a lack of understanding of what resources are required to support the organization's systems and applications.  They are increasingly tasked to do more with less, all while meeting standards for security and financial transparency.  Money for proactive initiatives is often non-existent and support only shows up after an issue has already transpired, along with accusatory questions on why this was allowed to happen.  When everything is running smoothly they hear "What do we pay you for?!"  When something breaks, they hear, "What do we pay you for?!"

In my, albeit anecdotal experience, there is clearly a cultural gap that needs to be overcome and Enterprise Architecture is the mechanism by which it will be bridged.

In chapter 1 of the course text, the bit (page 6) about the organization trying to "build solutions, rather than capabilities," really resonated with me because it perfectly describes an organization without an EA, where every system is on an island and interoperability, if it exists at all, is likely a cobbled together, undocumented mess.

How did we get here?  It's not necessarily due to negligence.  In every IT organization I've been a part of, there existed some (very) legacy systems that came from mergers/acquisitions and still exist because contracting a maintenance programmer is much cheaper than what it would cost to migrate the system to newer technology.  The truth is, most start up organizations do not have the luxury to be doing EA right out of the gate and in most cases their IT ecosystem isn't complex enough to warrant it.  And many of those start ups will fail (not due to a lack of an EA.)  But the ones that succeed and grow come with a ticking time bomb.

There is tremendous opportunity out there to garner value by more tightly coupling technology with business strategy and the first step on that journey is to bridge the culture gap within the organization.