Blog 07: In-sourcing

Chapter seven of the course text concerned itself mostly with enterprise architecture's role in how organizations outsource.  This has been a bit of a hot button topic in the Information Technology space over the last 10-15 years as more and more of IT services have been outsourced to much cheaper offshore firms.  The chief driver of this has always been cost; it is going to be cheaper to farm your code out to a shop in Bangalore, Hyderabad, or Shanghai than silicon valley.

My organization has been no exception, it was not uncommon for employee IT project managers to be overseeing large offshore development teams for in house applications.  The upside, of course is cost. The downsides are a bit more subtle, with time zone and language differences eroding away some of the value the low cost brings, not to mention, the contracts are often for a specified time, not created application features.  This means that a single application with a long development cycle may have multiple different contracting firms working on it, each with their own unique style/ability, leading to the next vendor having a learning period to figure out what the last vendor was doing code wise. It can be frustrating to deliver results like this.

Fortunately, executive leadership took notice of this trend and there is a big push from senior management towards "in-sourcing."  The goal is to retain and develop talent and keeping them on as internal employees has the added benefit of encouraging more long term thinking from the developers, they're no longer thinking in terms of the end of their current contract, but are more invested in the organization and its goals.

Outsourcing still has its place.  IT infrastructure is essentially a commodity now.  Cloud services companies are taking advantage of economies of scale to provide IT infrastructure as service much more cheaply than all but the largest of organizations could hope to implement on their own.

The key lesson here is to outsource the hardware and retain the talent.

http://www.cio.com/article/3048805/leadership-management/ges-jim-fowler-on-the-cio-role-in-the-digital-industrial-economy.html

Blog 06: An Uncertain World

I'm going to take a slight departure from my usual format this week to talk about the Great Britain's historic vote to leave the EU.  Up until just a few hours before the final vote count, all indicators pointed towards the "Remain" side of the referendum winning by a slim margin.  The global financial markets, which had hedged heavily on the side of "remain" in trading right up until the evening of the vote are now in disarray.  This volatility will no doubt stabilize over the coming weeks as a better understanding of the full ramifications of the "Brexit" are understood.

So what does any of this have to do with EA and specifically the implementation of EA future views?  It makes me wonder: what happens to the best future view if circumstances change prior to its implementation?

I was speaking with a colleague of mine yesterday morning who is in Germany.  He was in the middle of the design phase of a project to migrate some applications from a data center in Austria and had to options for his destination: 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.  All of that analysis was turned on its head this week and everything is moving to France.

The EA life cycle operates on a scale of years.  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.  

Blog 05: Technology Viewpoints

I've spent the last several blog posts talking about the potential issues in implementing EA primarily due to the differences in goals between the "technology" and the "business" sides of the organization. Clearly these two groups have different short term priorities and ideas on how the greater organization should realize its goals.  This week I'll be taking a deeper look at the technology side of the equation, because the same struggle that occurs at the larger enterprise level can also occur at the departmental level.

"Often, different IT constituencies, such as infrastructure planning and enterprise architecture (EA), drive separate planning activities. This duplicative approach is more than a waste — it is a roadblock to achieving valuable standardization that can be useful in practical, per-project behavior among daily activities." (Robertson, 3)

 This quote from the Gartner article (G00135179) is on point.  In my experience differences of opinion within the IT organization over what may ultimately be two technologies that do the exact same thing are even greater than the rift between IT and the business side. Both sides of the argument are firmly entrenched in their positions and unwilling to budge; it's no longer about what's best for the organization (in this case, coming to agreement and moving forward with implementation) but which side is RIGHT.  And much like a religious schism, there are often no winners.  The United Church of DB2 fragments into the Cult of Oracle and the Reformed Church of SAP R/3.

Gartner's Technology Viewpoints are a solution to this problem.  Describing the IT ecosystem in terms of technical components, groups of technical components, and linking them specifically back to business value will refocus the argument not on the merits of a specific technology, but on the output of that particular portion of the architecture.

Blog 04: All in for EA

Reading through this week's reading really provided no new surprises.  Chart after chart, figure after figure, real life example after example, the message is clear:  The greater the architecture maturity, the more more savings and the lesser time to market.  It's just so OBVIOUS.  But why is it so hard to implement?

Doing EA...I mean REALLY doing EA requires a holistic approach and generally speaking, the starting point state for the IT ecosystem is 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, see blog 01) 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. But my finance 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.
  

Blog 03: Laying the Foundation

I strongly agree with the premise of chapter 3 in the course text, that very often organizations confuse IT Architecture with Enterprise Architecture.  It's not so surprising, considering EA is all about integrating technologies with business strategy and process.  Strategy is pretty intangible, while IT infrastructure is comparatively much more real.  It is trivial to measure the number of servers stood up, the number of transactions processed by a new system, or the square footage of a new facility than it is to realize a strategic goal.

I posit that many organizations fall into the IT architecture trap because of the granular nature of many IT initiatives.  They represent quick and easy wins.  "Look what we accomplished last quarter!"  It is much more difficult demonstrate the business value, especially when putting the cart before the horse.  Organizations think they're doing EA when all they're doing is IA.

Too often technologies are selected because they are trendy or well marketed.  This is when the buzz words start flying around, I'm sure you're all familiar.  Agile.  Big Data.  Cloud.  Data Lake. Internet of Things. Software as a Service.  These  concepts/technologies are great tools that may be leveraged to accomplish a goal, but they are not the goal.  Organizations that select a technology and model their strategy around that technology are often shocked that their customers (internal or external) want nothing to do with their product.

Having a clear understanding of customer wants/needs defines business strategy, which in turn defines technology.