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.

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.