I've mentioned before the best part of my unofficial job is that I get to have some pretty intense discussions with customers who are sometimes up to pretty big stuff.
Last week, I had two such discussions (on the same day!) that ostensibly looked like the same thing going in, but went down two very different paths as they took high-level concepts and mapped them into priorities.
I've written about these sorts of engagements before (here, here and here), and I think they're interesting journeys into the real world of IT strategy.
I hope you agree.
The Morning Visit
Large financial institution. Massive IT landscape.
Goal of project: huge cost takeouts, while preserving service levels and improving flexibility and responsiveness of IT.
The mandate to do this was relatively mature: teams had been formed, workstreams started, initial project proposals were starting to emerge.
They had gotten to most of the quick wins: negotiating with vendors, commoditizing parts of their environment, tactical headcount reductions, and so on.
But in the big scheme of things, this was targeting dimes and nickles, rather than hundred-dollar bills.
What they were really looking for was the order-of-magnitude win -- how do we put this infrastructure thing on a whole different footing?
They had a few technology areas they wanted to discuss with EMC: storage rationalization, server virtualization, file and storage virtualization, enterprise management, data reduction, a bit around security -- a familiar list.
Clearly EMC had a lot to say here: not only did we have the technologies they were looking for, we knew how and where they worked well. We had the people who could show them how to use them now, and in the future model.
As the discussion evolved, all of the sudden the conversation took a serious turn.
"People issues" were somewhat acknoledged as part of the context: too many of them, wrong skill sets, not aligned, etc. And it wasn't something they seemed to feel comfortable talking about.
I thought we were getting into very important subject -- shouldn't the people model be an integral part of the next-gen IT thinking?
Put differently; putting new technology in front of a traditional IT skills model means that you do the same things you did before, just with nicer technology.
Hard to get an order-of-magnitude improvement by just considering the technology model outside the context of the organizational model.
We spent a fair amount of time discussing emerging organizational models that we had seen that support transformational IT. What are the new roles, what are skills you invest in vs. outsource, how do you define the model and get people to it, and so on. No definitive answers, but some concepts that seemed to get some traction.
A little later on, we were reviewing the technology stacks they were considering, and we hit another "aha" moment.
They had one stack team for server technology. Another for storage technology. Another for middleware, and network, and management and so on.
So I started to probe a bit, and offered up a few examples where considerations in one stack could considerable impact (or optimize) another.
I used VMware as an example (back story is here). Yes, the server/OS team had standardized on VMware for a big piece of the puzzle, but how did that impact the storage team? The backup/recovery team? The enterprise management team? And so on.
A good decision in one place could ripple across the other stacks, and create either chaos or opportunity, depending on how you looked at it.
As another example, they were moving to a SOA architecture. From my perspective, that's an important design point when considering a number of disciplines (see here).
Bottom line: all the stacks looked rational by themselves, but they didn't have a process or methodology to integrate the "tops" of each stack, and look for synergy or conflict.
And I thought it would be very, very hard to get to that order-of-magnitude outcome they were looking for without (a) looking for "big impact" integration opportunities across the various stacks, and (b) maybe think explicity and formally about that new stack we were discussing, the "people model".
And, of course, we went through all of the relevant technologies and how they would work in their envisioned environment.
That part was expected, I think. What I don't think was expected was the somewhat deeper discussions that we got into.
And that was fun.
All very good and beneficial to me -- I enjoyed it greatly, and I think they did as well.
The Afternoon Visit
Another financial institution. Not nearly as big, of course, but just as important.
They too were getting to their next-gen architecture. But they were coming at it from an entirely different angle.
I don't know if they had read the book, but they had embarked on a classical enterprise architecture transformation -- the kind that you read about. Complete re-engineering of core business processes, information management, and so on.
This was the real deal.
They had done the "one slide" that's essential to a serious enterprise architecture discussion. And it made total sense.
So, my usual approach in these situations is to talk about the final state environment, all the issues you'd be likely to have, and then position EMC's capabilities.
About 3 minutes into it, he stopped me.
He said "I'd really like to have those problems some day. What I need help from you is in getting to that point".
I asked him -- what do you mean?
Test cycles were taking too long, and were totally disruptive to the business. They added more people, schedules lengthened, there was more and more friction with the business, and tempers were getting short.
In an ugly world, people would throw in the towel, and that would be that. They'd never get to the point where they could even consider some of the stuff I was talking about. Ooops.
What could EMC do?
It put the discussion in an entirely different light.
So we started with the concept of a rapid test harness. Did they have a capability to set up a test environment rapidly and non disruptively, run their tests, and reset the whole thing in an instance? Remember, we're talking enormous databases that have to be captured, transformed, tested and re-tested over and over and over again.
From a technology perspective, this translates into local replication (e.g. TimeFinder) that can handle the rapid re-instancing of large data sets, as well as VMware's Lab Manager, which can create a server-oriented test harness to complement.
The net result is that the test harness allows the team to do far more testing in a far shorter time, and hopefully a lot less disruptive to the business -- either by grabbing the data cleanly, or introducing the new environment with a quick fail-back capability if it's a bad IT day.
A related problem was discovery. These migration projects had hundreds or more moving pieces of infrastructure, and the projects ran over a long period of time. They were experiencing change control issues -- something would change on either the source side, or the target side, and it wouldn't work, and they'd spend literally days tracking things down.
So, not surprisingly, we had something in our bag for this -- Smarts ADM (formerly nLayers). It couldn't solve everything, but what it could do is probe a good deal of both the source side and target side, and not only verify proper configuration (hardware, software, relationships, etc.) but also track any changes that might have been made on either side that perhaps weren't documented properly, and cause subsequent havoc.
I know that never happens, but just in case.
Another satisfying deep discussion that resulted in some non-obvious wins for us and the customer. We could have gone another hour, but we had to move along.
Putting It All Together
Yes, vendors (including EMC) have products that can be part of next-gen IT.
And many vendors have services guys who can help in applying the technology.
But I think that we're privileged that we have enough capability in our portfolio that we can occasionally offer more than the usual stuff, and take a few of the things we've seen in other situations, and apply it freshly to the customers we work with.
And the best part is that we get to talk to real people about real problems.
Comments