I have this memory way way back as an undergrad completing the IST program of being confused about intermediary levels of abstraction.  Specifically, we learn about bits, bytes, ones and zeros as the building blocks of all things computer.  A little later on, a lot of the math behind why this is so powerful….IST 230 I think, with truth tables, Boole & De Morgan, and propositional logic concepts.  In my case, I actually got a little more practical experience with this stuff, I took a few CSE courses my first semester and one of them was a digital logic course where we built out logic circuits on breadboards.  But then, all of a sudden, it’s coding classes, jumping a couple levels of abstraction.  Yeah, they mention assembly and how the code is compiled and linked into machine code….but they never really EXPLAINED how that works.    (As an aside, if you enjoy puzzle games, check out TIS-100 by Zachtronics.  It’s a puzzle game where you solve problems by coding in a psudo assembly language on functional 8088 era hardware and it’s a blast!  http://www.zachtronics.com/tis-100/) 

Now, in my case, I had completed CSC 120 prior to switching to IST, so that counted as my first three programming credits.  That was in C and we learned about pointers and memory management…contrasted with IST 240 a few years later which was programming in C# which has a garbage collector…memory management didn’t come up once.  So where am I going with all of this?  I sometimes feel the same way about EA models…and to a lesser extent, to IT road maps/blueprints.

I’m sick of sitting in meeting and having people speak in such high level terms that they’re not actually SAYING anything.  Oh, IT is moving from a vertical to a horizontal organization!  Ok….so what does that mean?  We’re doing the exact same things now that we’ve been pulled out of the various different divisions into a centralized shared service, except now I have “two” bosses and am doing the exact same thing.  Or on the EA side of things, you can look at a high level model all you want, but a lot of times you can’t tell if a process is a robust IT system or a literal “swivel chair” person reading data from one system and entering it into another.  Models are great tools for documenting systems because lots of times they omit levels of granularity that decision makers simply don’t need or don’t care about…but it is absolutely critical that someone somewhere is still aware of the details and involved enough to be able to raise the alarm if things go to far off the rails.

I read through the Gartner job description for an Enterprise Solutions Architect and that fits my day to day responsibilities to a T.  The thing I struggle with is everyone wants to deal with the high level concepts and skip over the details of how the work actually gets done or how the system actually needs to function.

Again, this week’s topic dovetails nicely with a lot of what was covered back in EA 873.  Last year I was actually able to put my modeling skills to good use at work.  I was working as an infrastructure IT project manager for GE’s Power business at the time.  In the months right after GE’s acquisition of Alstom Power and Grid, the integration of the two massive groups was not going so well.  GE Power at the time was ~80K employees globally and Alstom was right in that same neighborhood. We especially had some difficulty with a lot of the service delivery components for basic IT servicesm e.g. ordering a PC and using it to access certain applications.  The trouble was, while the networks were ostensibly integrated, due to them both using overlapping private IP ranges, it was really two networks with some really fancy DNS scripting.  To make matters worse, a lot of the legacy Alstom resources were not running in strategic data centers, but sitting at remote sites in a closet, on some goofy domain that was causing issues.  Like I said, things were a bit kludge.

The end user support folks were getting hammered, because of the nature of a lot of the issues.  Brand new PCs were arriving missconfigured or employees were only able to access legacy Alstom or legacy GE resources, but not both at once.  As a stop gap, I was tapped and put on a special project to get to the root cause of the issues since IT at this point was looking pretty bad.  (My first role with GE was with the client team, so I had some experience in the service management area).  Things got off to a rocky start.  Basically everyone was using the team as an excuse to skip over the service desk.  The service desk was having trouble with integration issues, but we found very quickly that EVERYTHING all of a sudden was an “integration issue.”  The sheer volume was overwhelming, but the powers that be, in this case the non-IT business leaders who were hearing the complaints and sending folks to us simply didn’t care.  They couldn’t, or wouldn’t, understand what was going on and everyone was concentrating on fixing symptoms rather then fixing the causes of all the issues.  I created the following capability model which very clearly outlined the various roles of all those involved and detailed all responsibilities from start to finish.  Got a nice pat on the back.

Stakeholders

• End User – The actual end users with the issue.  In practice, these are often executive level employees
• Integration Team War Room – The first attempt at a collaborative helpdesk containing contract resources from both GE and Alstom service desk vendors, specializing in integration related issues
• Corp Shared Services Resources – This includes the regular GE service desk as well as the level 2/3/4 domain specific resources, e.g. email, AD, single sign on, Identity Management/HR, etc
• PT SWAT Team – My group, comprised of various project managers from GE Power’s HQ IT function, with expertise in End User/Client and Network.  We have a higher level (in scope) of technical understanding and a much better professional network within GE Corporate IT
• Business Integration Leadership – This are business and IT leaders from both GE and GELA who are fielding calls from angry executives and put the SWAT team together

Process

This process STARTS after the regular service desk process has failed.  An end user who is not getting resolution to their issue escalates to the integration war room.  If they are unable to resolve, they create a ticket in a support queue spun up just for the SWAT team.  Often, information provided from the war room is incomplete or incorrect.  SWAT team works directly with end user as needed to triage issue.

Once issue is understood, SWAT team engages L2/L3/L4 teams as required while retaining ownership of case and acting as facilitator until issue is resolved.  Once resolved, the steps to resolution are documented and provided to the regular service desk and a RCA/status update is provided to the business integration leaders.  We will follow up with the end user in a few days to confirm issue resolution.

The SWAT team’s stated, internal mission statement, is to make ourselves as redundant and unneeded as quickly as possible by ensuring solutions are discovered quickly and documented sufficiently, so we can get back to actually doing our real jobs.

William Ulrich does a nice job of defining business architecture in the reading “The Essence of Business Architecture” but I want to take it another step forward.  From my perspective as a career IT guy, BA and the resultant modeling that comes with it operates at a higher level of abstraction than IT systems.  Rather than dealing with information and data flows, it deals in business capabilities.  If you think of the IT OSI model, BA would occur on top of it all, off the page.  In fact, going back to the Scott Bernard “EA Cube” from way back in EA 871, BA is really synonymous with the “Business” portion of the model.  The technology may be the underlying infrastructure for how information flows and data is stored, but BA is the unifying glue that holds the entire thing together, unless your organization is doing IT simply for the sake of IT, rather than generating business value.  Which, to be fair, is a mistake I’ve seen some organizations where Enterprise Architecture is dominated by IT personnel make.

Starbucks Process Map

Last fall when I took EA 873, I had the opportunity to generate some actual models of business process capability models, so I’ll discuss a simple one here.  As an undergrad, I worked for Starbucks as a barista.  The model to the right is how we would end up processing a beverage transaction.  Note that things are only dealt with in the abstract, we’re talking about transactions, people, and products.  Completely missing from this diagram is all the supporting functions and process that enables these higher level functions.  For example, the registers transmit drink orders directly to the espresso bar.  Based on the number, type, and size of those drinks, the inventory system knows how much milk, coffee beans, cups, etc that was used and can order more accordingly in the next delivery shipment.

The key take away here, for the business analyst, is to not get caught up in the details of the inside of a process step (unless that particular step itself is being modeled).  Instead, BAs should focus on the inputs and outputs of a particular process, along with any constraints involved.