I received some bad news yesterday afternoon, that my job (along with everyone not located in four specific offices, ~200 IT folks) is being eliminated.  Obviously this is not news anyone ever wants to get, but it gives me an idea to cap off my final blog entry for EA 874, as well as the EA MPS program which I complete this semester.  Flexibility, flexibility is key.  So what does any of this have to do with EA and specifically with evaluating emerging technologies?  It makes me wonder: what happens even with the best analysis, you find yourself betting on what ends up to be the wrong future tech.  

It reminds me of a discussion I had with  a colleague of mine last summer who is in Germany (where EU labor laws make mass layoffs quite difficult!).  He was in the middle of the design phase of a project to migrate some applications from a data center located in Austria and had two options for the destination: data centers in London or Belfort, France.  All of their planning and analysis said London would ultimately be the best choice, for a variety of reasons, cost, accessibility, and future scalability.  But then the unexpected Brexit vote happened  and all of that analysis was turned on its head.   Long story short, everything was moved to France.  The EA life cycle operates on a scale of years, much longer than the rate at which new technologies appear on the scene.  Business disruptions can come suddenly and unexpectedly.  This really leaves two options.  1) The EA must be robust enough to account for major disruptions, e.g. a plan “B” or 2) the organization must be prepared and willing to pivot in response to the unexpected disruption.

So, perhaps it’s fitting that I’m about to be starting a new chapter in my professional career now, right as I’ve completed the EA program.  Whether professionally or personally, life constantly will throw you curve balls.  The only thing you can really do is be prepared.

Reading through this week’s reading really provided no new surprises.  Enterprise Architecture is not rocket science, it’s obvious!  But why is it so hard to implement?  Communication problems, IMO.  So many EA initiatives are doomed from the start because critical stakeholders only pay lip service to the initiative.  Or as the BAInstitute.org reading put it “The Struggle for Understanding”

Doing EA…I mean REALLY doing EA requires a holistic approach and generally speaking, the starting point state for the IT ecosystem is going to be very fragmented, with duplicate/redundant systems.  Sometimes there are silo/standardized technology hybrid systems. For example, up until ~2013, my organization kept and managed two different Configuration Management Data Bases which were running on separate instances of the same platform.  The reason for this redundancy was 100% political and as all too often, technical best practice takes a back seat to a high performing profit center who wants all of the autonomy and none of the accountability.

So, you may ask…what’s the harm? If the business wants to architect their own IT solutions (probably due to a sense that IT is too slow/too expensive) why not just let them?  Because you end up with organizations with more hidden silos than NORAD.

“Even though we spent hundreds of millions of dollars on the infrastructure…we we’re spending it anyway.  That’s the fallacy in what most people think.  When it’s being spent in departments and in divisions the money is being spent.  It’s just not being seen.”

The above quote from Charlie Feld is especially relevant.  Various departments enacting IT solutions all on their own is not going to save you money…and that’s not even factoring in the cost to maintain or fix their “shadow IT” infrastructure.  But this situation often arises, because the business may believe they can do it cheaper/better than IT.  And maybe the dollar amount IS less in the short term, but it shows very little fore site.  Here is a fairly recent example that drives the point home.

A few months back I was responsible for replacing a few generators that are the emergency backups for one of our data centers.  It was competitively bid out, I made my selection and then immediately ran into a wall with finance. They demanded to know why I didn’t choose the lowest cost bids for the generators.  (Some background.  my org is huge and makes a lot of stuff, generators included.  The bid back from our own company, but different division cam back about 10% higher than an outside bid.)

My thinking was, I was taking money out of one pocket and putting it in another.  From the shareholder perspective, the transaction was cost neutral, all internal to the company. In IBM parlance, the difference between BLUE dollars and GREEN dollars.  But my finance team person didn’t see it that way, she saw it as more money leaving our cost center than was required.

Ultimately it’s decisions like this that defeat EA before it has a chance to shine.  EA must be championed by executive leadership and the organization must move towards the same goal in concert, otherwise the effort is doomed to failure.  And you get those guys on board by communicating clearly to them why exactly EA is good for them.

I spent most of today still being sluggish from all the Thanksgiving eating I did yesterday, but I did start to draft out my rough outline for the individual research assignment in 874.  I found a short blog article that doesn’t really cut the mustard for a scholarly source to use in the paper, but it certainly fits the bill for blog discussion fodder! http://www.ciodashboard.com/technology-innovation/3-approaches-emerging-technology-experimentation/

The short article discusses three types of technology evaluations that organizations can take and they’re pretty high level.  The article reminds me a bit about organizational process maturity.  The three levels are:

• Vendor-Driven –   This is when the organization can’t or won’t evaluate technologies on their own, instead waiting for their vendors to approach THEM with solutions.
• Technology-Driven – This is when the organization begins to experiment with new technologies without any regard for business need or current capability.
• Business-Driven – This is when the organization does experiment with new tech, but first evaluates their current and future capabilities.

So, it’s pretty obvious from the get go that Business Driven is the correct route, so I will talk a bit about how an organization may accidentally end up in one of the two non-optimal situations.

Vendor Driven – Organizations that end up adopting new technologies via their vendors and service providers probably are running a bare bones type of IT outfit.  Low budget, understaffed, the few IT personnel that do exist are likely working on projects very reactivly, e.g. fixing/upgrading systems only when they break, rather then under their own terms.  Yes, this method for sure entails the least amount of risk, however vendors are likely to only feed them cookie cutter configurations of off the shelf software.  Probably not the most efficient way to enter into a new technology space and they will be beaten to this space by all their competitors who did not wait for a vendor to try and sell them something.

Technology Driven – This is the complete opposite situation of vendor driven.  In this case, the IT likely has a budget for new product introduction or otherwise has the agency to spin up prototypes and proof of concepts for new tech.  The biggest mistakes I see with these types of organizations is getting too focused on a specific technology and trying to shoehorn all their existing systems into this “next big thing.”  This wouldn’t be a problem, except for the fact there is always the next new big thing right around the corner and they’re on to discovering a new tech before the organization has had a chance to upgrade to the last one.