Blog 12: Course Retrospective

As the semester is winding down, this will be my last blog entry and I thought it would be a good forum to discuss my impressions with EA 872, what I liked and what I disliked. For context, I'm in the EA MPS program and took EA 871 last semester.

Start Doing

• More real-time class sessions - I really enjoy the real time class sessions and lack of this person to person interaction is the single biggest detriment to the World Campus model.   Obviously most of us are working professionals with families and have all the responsibilities that come with that, so keep them optional and maybe vary the times to encourage participation from folks in different time zones.
• More Forum Discussions - Since having the entire class together at one time, even virtually is not an option, the course should leverage the discussion forums more heavily to generate discussion.  I love hearing from other folks with different opinions and from much different backgrounds than I have.

Stop Doing  

• The blog! -  Ironic, I know, but blogging was probably my least favorite aspect of the course.  I think a lot of the value of blogging can be made up in increased forum discussions and I just feel like the blog is a little too one sided, especially when I start pontificating on how awesome IT is and how the "business" side always messes things up.  Dialog would be easier with a more threaded view.

Continue Doing

• Group Projects - I enjoyed this course's group projects because it was really four pieces of a larger initiative.  Analyzing a single organization and applying the new concepts we learned along the way was very helpful in my understanding of EA and moved a lot of things from the abstract to the more "real."
• Gartner Articles - The Gartner articles are always interesting, but I notice from the dates that they are a few years old.  Not sure if they don't have anything more recent, but would be nice to see because even ten years can be an eternity with EA due to the rapid changes in technology and markets.  

In closing, would like to say that I really enjoyed our discussions and reading your blogs this semester and look forward to working again with you all in future courses. 

Ben

Blog 11: IT Strategy

IT strategy is probably the most often overlooked activity for non-IT leadership in pretty much every organization I've been a part of.  They just don't care.  They want technology to be always available and they want it as cheaply as possible.  IT is a "support function" that only exists to enable the parts of the business that make money.  I think historically, this has been true, but it hasn't been for quite a while now.  Truly successful businesses will recognize that IT needs a place at the table when important decisions are being made.

Yes, I'm biased, having worked my entire professional career in IT.  I understand that most non-IT folks don't fully appreciate what it takes to keep everything running smoothly.  My guess is this is a direct result of the proliferation of consumer grade computing and networking gear over the last 15 to 20 years that gives enough of a familiarity with the technology to make assumptions like my home network runs of a $50 Linksys from Best Buy, why can't the enterprise network?  Or my home cable modem is $75/m for 100Mbps...why do we pay $6000/m for a pair redundant 100 Mbps MPLS circuits?

Now, I certainly don't expect everyone to understand the differences in those two examples and I actually rather like that those questions are asked.  It's never good to become complacent and challenge all parts of the organization to do more with less.  That said, when it comes time to fund IT maintenance activities or replace older technology...it seems like everyone involved is anchored on the lower perception and every budget dollar has to be fought for.

No business function can exist in a silo.  As high of an opinion as the sales team has for themselves, they can't do it alone...no business function can.  But unlike accounting or sourcing or HR, the ability of IT to create business value has been growing exponentially over the last few decades.  IT infrastructure and services permeate not only all business functions, but also represent an interface with external customers. It seems crazy to me that IT is still excluded from strategy discussions in some organizations.

Blog 10: Measuring EA

I love this week's topic because it isn't even specific to EA initiatives.  It's something not a lot of people think about.  Most folks seem to focus on quantifying/tracking a business statistic...but what they SHOULD be doing is validating the action that they THINK is causing the metric to change.

It is a very rare occurrence to have a situation with only a single variable.  More often it more complicated or multiple variables acting in concert, sometimes with odd synergies that can be very difficult to determine.  Did sales increase because the engineers added a new feature to the product or because of the marketing department's new social media add campaign?  Was it both?  Perhaps neither, such as an external factor, such as a distribution issue with a competitor?  It's easy to reduce a complex system down to a simple cause and effect, but my ultimately be a lie.  And you can bet that while both marketing and engineering were patting themselves on the back and each taking credit for a positive trend in the metric, they both will be distancing themselves from a negative trend!

I read Eric Ries's "The Lean Startup" a few months back and he actually talks about this at some length, in the chapter titles "Measure."  True this is specific to measuring success (or failure) in a startup environment, but these concepts translate over to EA.  He says that metrics should be "actionable, accessible, and auditable."

Actionable - the metric should demonstrate a clear cause and effect
Accessible - the reports should be well understood by the viewer and not require explanation
Auditable - the data should be consistent with reality.  The results of an automatically generated report should be the same as a person asking customers questions.

The parallels with EA are pretty clear.  The first question leadership is going to ask when pitched an EA plan is going to be "How will this make us money?"  The second is going to be "How do we know EA is responsible for our success (or failure!)"

Ries, E. (2011). The lean startup: How constant innovation creates radically successful businesses. London: Penguin books.
 

Blog 09: Governance

I don't think I've yet met anyone who enjoys the governance aspect of the business.  It's almost invariably seen as a necessary evil, something that's required that costs more resources than the value it generates.  The documentation involved is often loathed as needless "busy work" probably because (at least in my organization) all of the supporting forms and workflows and meeting rhythms that have been developed to support it.   But what I've noticed about a lot of these support mechanisms, is that once they've been implemented, they are hardly ever revisited.  No one seems to ask the question:  Is there a better way to be doing this AND still be compliant?  So you end up with folks on your PMO's project tollgate calls or IT operations CABs who are more concerned with the administrative minutia, i.e. the letter of the law, while ignoring the spirit.  Something is wrong with your process when something is rejected and has to wait a week until the next call because a file attachment on the form used an improper naming convention.

Stuff like this makes me shake my head.  It also reminds me of the most probably apocryphal story of  the "Five Monkeys."

      
I guess the lesson here, is yes, governance IS important, but never lose site of your goal.

Blog 08: Mergers & Acquisitions

I've mentioned before in previous blogs about how I used to work for a P&L within my current organization that had 24 different ERP systems.  This was not an exaggeration.  They ranged from Oracle, DB2, SAP, a hacked together system using the 1996 version of Apple FileMaker, and my favorite: A 30 year old system written in FORTRAN and running on DEC Alpha hardware that still occasionally throws errors that say "If you see this, call Bob." Bob retired a long time ago.

Most of you are probably slapping your heads, I know I did when I first discovered this. But to understand how their IT got to that state, you have to understand how that organization became an org.  When the parent company decided to make a strategic entry into an industry they had no presence in, they began acquiring companies. Word got out and soon other companies were acquiring smaller firms, in the hopes of making themselves more attractive to be bought.  Let's just say that the integration efforts in those cases was...not good.  So, as you can imagine, this situation is the first thing I thought of when I read the section in chapter 8 on managing EA through mergers and acquisitions.

It wasn't just the IT ecosystem that was fragmented.  The rapid string of acquisitions had a lot of the personnel on edge, as many folks were let go to avoid duplicate roles.  In the IT space, everyone thought that the way their legacy organization handled things was the ONLY way to do things and there exists even today some animosity between employees who were around during the time of the merging.  There was a lot of fighting, a lot of strong, differing opinions. Now, almost 15 years later, they are down to a single ERP.  Basically.  There is still an old OpenVMS system hanging around in read only mode due to containing information that must be available for regulatory reasons.  The more tenured folks still complain that the ERP system isn't as good as their home grown FileMaker solution, but there is peace, more or less.

This is why I firmly believe that effective communication and managing change is the most critical piece of EA.    

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.