The New Hotness: Software Defined Storage

One thing I love about the industry I work in is the great passion and the awesome competition for ideas that we have.

One thing I really hate about our industry is all the people who just take their existing product and then re-label it as the new hotness.  Come on people, you're better than that.

Just as Cloud before it and SDDC more recently, the term "Software Defined Storage" (SDS) has suddenly become very hot in the storage industry.  Amazingly, it turns out that almost every storage vendor ALREADY HAS a great SDS product that they've been making for years!!  WOW!  These guys are really good.

Wait, what?

Yes, that's right.  Now that SDS is hot, everyone is simply claiming that their product is already a great SDS platform (surprise!).  Sometimes they do this by simply redefining the term (see here for example).  Others just blatantly ignore the facts.  Still others do actually have really cool SDS products.

You can see the problem here.  Those not very close to the subject quickly become confused.  What does this term actually mean?  What should I do about it?  Is this something I should really care about?  This then becomes FUD (Fear, Uncertainty and Doubt) that prevents truly great products from being adopted because of all the noise.  You can see this happening with SDS on Wikipedia where they claim SDS is simply a marketing term and doesn't really have a definition or purpose.

That's really sad because SDS is actually one of the more revolutionary things to come out of the storage world I quite a while.

So, what is SDS, really?

 

Software Defined Storage (SDS) is a Storage Management Architectural Pattern that allows for the remote management and configuration of storage assets.  Because SDS is a management architecture, it is completely abstracted from the underlying hardware infrastructure.  In other words, SDS describes a “Control Plane” architecture that is separate and distinct from a “Data Plane” (or “Data Path”) architecture.  SDS is being driven by the movement of datacenter architectures to highly automated, policy driven management frameworks (such as VMware’s vCloud Suite or OpenStack).  This movement is closely related to "Cloud" and to what is sometimes referred to as "Software Defined Data Center" or SDDC.  These frameworks require highly abstracted management layers in order to isolate the Cloud Management Framework (CMF) from underlying infrastructure details and/or changes.  There are three main components to these Cloud infrastructures:  Compute, Storage and Network.  SDS is the control plane for the Storage component of cloud infrastructures.

SDS has the following mandatory attributes: 

1)      All functions must be available via a simple remoting interface.  This is normally done via a web style (SOAP, REST, etc.) interface but this is not a requirement.

2)      SDS is defined as a “Control Plane” or out of band management channel.  This is normally done via an IP based management network but this is not a requirement.  Note that SDS cannot be implemented in band by definition due to the restrictions of physical connectivity.

3)      SDS solutions must offer a single control plane (also referred to as a “control surface”).  Underlying systems can be disjoint or multi-vendor but the SDS solution must be unified to claim that it is actually a SDS solution.

4)      SDS is independent of the “Data Plane” or I/O path.  This implies that all current and future storage protocols (FCP, FCOE, iSCSI, NFS, etc.) can be driven by an SDS based interface.  However, all dependent components must also be managed by a single control plane.  For example, FCP based solutions must have a single control plane for zoning and LUN masking.

5)      SDS implies deep integration with physical storage assets and supported operating systems and hypervisors.  Being able to present, remove, backup, replicate and perform other storage operations implies a deep level of integration with the underlying physical asset and the hosts (physical or virtual) being serviced.  However, SDS does not specify how this is performed.  SDS is not synonymous with virtualized storage.

 

It is important to note that SDS is not synonymous with cloud nor is a SDS compliant platform required in cloud scale architectures.  However, SDS does provide many of the storage abstractions required by these types of architectures.  Also, SDS is not synonymous with “Virtualized Storage” which is also commonly associated with cloud scale architectures.

It is important to note that abstraction and “virtualization” of Data Plane constructs (LUNs, iSCSI, Storage Aggregation Layers, Storage "Hypervisors," etc.) is separate from but related to control plane constructs.  Innovations such as auto-tiering, Flash based cache, de-duplication, virtual storage controllers, software based arrays, etc. are all concentrated in the data plane.  Each of these provides opportunities for SDS innovation via the control plane but they, themselves, are not directly related to SDS nor is SDS dependent on any one of these data plane technologies or architectural models.

Anyone care to offer a different definition?  Let's get it on!

 

Should Architects Evangelize?

When making radical changes to operating practice, you by definition will be injecting large amounts of change into the organization you are working with.  Things like private cloud are different enough that they will cause strain within organizations who attempt to implement these new technologies.  I find that there is an interesting dichotomy within the IT business around change and progress.  The business is populated by people who love technology and often pursue the latest bright shiny object just because it is, well, new.  Is it better?  Who knows?  At the same time, we work within extremely large infrastructures that are incredibly expensive to build and thus are very long lived.  These two things seem at odds and often create a type of cognitive dissonance that seems to escape some people.

This is especially true of the press covering the high tech world.  They’re always searching for that new thing which means that the tried and true technology that actually works usually gets short shrift.  If all you did was read the blogosphere or the high tech press, you’d think that things were very different than they actually are.  I spend most of my working life worrying about private cloud adoption.  This is something that’s been around for a few years now and you’d think that it’s a known thing.  However, the reality is sharply at odds with this.  Recently, I conducted an informal survey of about a hundred customers.  I asked them questions like “do you have a private cloud.”  Unsurprisingly, about 50% claimed to have one.  We then we asked, "do you allow self service provisioning?"  Very surprisingly, only about 50% of those companies said yes.  This means that only about 25% of the total (admittedly small) sample had even the most basic cloud feature enabled.  There’s always debate about what “cloud” really means, but pretty much everyone agrees that self-service is a necessary basic feature.  Let’s be clear, we didn’t ask if ALL their workloads were running on a cloud style architecture.  We just asked if ANY of their infrastructure supported it.  This means that the vast majority of enterprise workloads are not running on a cloud.  This may be a stunning revelation to those who are already talking about the "post cloud era."

As an architect, this is disappointing.  I really think that my customers can benefit from the concept of cloud.  Whether they buy my product or not, the core concept of cloud has immense power.  If they’re not aware of the benefits or don’t really understand the term, I can’t really help them reach their full potential.

This brings us to the question of evangelization.  The first person I ever met who called himself an evangelist was Guy Kawasaki when he worked at Apple.  His business card just said “Software Evangelist” which I thought was pretty cool.  I wish I’d been more careful with the card, I thought I’d kept it but couldn’t find it the other day when working on my new book about architects.  Sigh.

 

 

Being an evangelist is a funny thing.  Much like “Architect” the job description is a little fuzzy.  What I can say is that I know a good one when I see one.  For many companies evangelization is a key part of their business strategy.  Rackspace for example is doing an awesome job of pushing their agenda for OpenStack via evangelization.  Yes, they’re doing it for self-serving reasons, but they are also doing a great job of promoting what is essentially a free technology.  That’s good for all of us.  On the other hand, doing it poorly can be really annoying.  Not to be mean, but if you look at what my old employer, Microsoft is doing in this space, it’s not amazing.  The last OpenStack talk I attended by a MSFT presenter quickly turned into a naked sales pitch for their product.  The audience then checked out and started to disengage.  It’s a fine line, but you need to understand why Evangelization isn’t selling.

I bring this up because I believe that this is a key skillset and activity for the fully actualized architect.  Having a vision is nice.  Having a massive impact on the organization is what we live for.  The implication is that the journey to truth involves convincing others that your vision for the future truth is a big part of that journey.

If you’re a senior IT guy and you’ve never worked for a vendor in a customer facing role, this may not be an obvious skill that you’ve spent time developing.  On the other hand, I’m sure you understand that you need to have political support to get anything done.  Everyone’s heard the joke about the “Eighth Level” of the ISO stack.  In fact, the joke is so common that you usually don’t have to explain it to people.  I think that’s because it’s fundamentally true.  Like many things, it’s the shared understanding of the truth that makes it funny.

If you shy away from the term evangelist or if you feel this is really selling in disguise, think about how you would like to learn about something new.  Pick an area of technology that’s completely foreign to you.  Would you rather be exposed to that new area by a sales guy?  Or would you rather talk to someone you consider a peer?  Unless you’re strangely into self-abuse, I’m guessing the latter (no disrespect to sales guys…. OK, that’s a lie, it’s pretty disrespectful).  If you are learning about a new technology, do you want to talk to someone who thinks that technology is crap?  Wouldn’t that be a pretty short conversation?  “Hey, should I use the new FOO operating system?  Nah, that’s crap.”  OK.  End of conversation.  So, now you’re talking to a pretty technical person who’s really enthusiastic about something that you know very little about.  What do you call that?  Yep, evangelization. 

Now that we agree that evangelization is a vital part of an architect’s role, let’s talk about what it really is.

It’s selling.

Wait, what?  Didn’t we just agree that everyone hates a salesman?  Yep.  That’s true.  People hate being sold to.  Being really, really, good at selling means that you don’t really sell at all.  The true master salesman seeks to understand the customer’s underlying need and then satisfies that need.  When this happens, it’s called “customer service” which we all love.  When the salesman tries to force fit you into a product or solution with zero regard for what the customer really wants or needs, it’s called “being sold to” and most of us hate that.

I mentioned this in my book “Why we Fail” about enterprise adoption of private cloud.  The best book I’ve ever read about selling to technical people is called “Let’s Get Real or Let’s Not Play” by Mahan Khalsa.  In that book Khalsa introduces many awesome concepts, but one of them that I really like is what he calls “Peeling the Onion” to get down to what a customer really needs.  The implication for us as architects is that we need to understand both the underlying business requirements and the capabilities brought by the technologies.  It is by merging these two that we become evangelists.  Essentially, the future truth that we week to create is assembled by merging these two things.  This discovery process has many forms.  In most cases, all the information we need is hiding in the heads of those around us.  Despite our best intentions, most of the really critical facts are not written down and will never be discovered by browsing the web or reading whitepapers.  It is by talking to business stake holders, users, engineers, administrators and others that the architect can begin to bring those two domains into alignment.

Once you really understand where that overlap occurs, you form your vision.  You begin to understand what application, platform or service can satisfy the stated and un-stated requirements.  You begin your march towards that future truth.  However, you cannot do this by yourself.  Any serious enterprise system is going to be too large for a single person to implement.  This implies that you will require fellow travelers.  How will you recruit these brave souls?  How will you help them understand why the future truth you envision is superior to what they have now?  What secret superhero skill does the architect use to project this future truth onto others and entice them to journey into this great and glorious unknown future?

Wait for it.

Oh yes my brother; it’s evangelization. 

 

 

 

 

What's Worse than a Strategy Consultant? A team with no strategy.

I have to admit that I've done some really embarrassing things in my career.  And believe me, it's a long strange trip from a fresh minted UC Irvine Information and Computer Science grad to where I am now.

Along the way, I've had some really cool job titles.  Like "Technical Director" or "Director, IT Architecture."  You get the idea.  However, one job title that struck me as wrong an still sounds absurd to me is "Principal Strategy Consultant."  I mean, if anyone tells you that they are a strategy consultant you have to question what they actually do.  And to be a "Principal?"  Does that mean you're the king of the do nothings?

What it actually meant is that I got paid to go into businesses, ask dumb questions and then tell them what they were doing wrong.  Man, I loved that job.

As you can imagine, this gives me a funny way of looking at the world.  Or to be more accurate, I'm pretty f'd up and that job just brought out the worst in me.  My first boss told me that I had a "Columbus Complex."  He explained that meant I would take a look at a map, figure out that the shortest path from A to B was a straight line and to hell what any of the "experts" said.  Those of you who know me: you can stop laughing now.  After all, old Chris was right.  Let's forget that he thought the Caribbean was "East India".  I mean, it IS EAST OF INDIA, right?  So, two points for trying.

Getting to the point here, I'm a long term guy.  When I talk to people about their products or their services, I'm always looking at a multi year horizon.  That's not really "long term" for other industries like the guys who manage forests or something but it's pretty long term in the technology business.  Looking five years out in our business is really tough.  It's so difficult in fact that many product teams that I've worked on don't really try.

And that's a shame.

I call it "Lack of Strategic Context."  Which is a fancy way of saying you have no clue where you're going.  A director I was talking to the other day put it this way: "Why are we debating if you should take the train, fly or drive?  You don't even know which city you're going to."

You see the problem?  If you have no destination in mind then you're just wandering in the desert.  That's no way to lead your tribe, my friends.  Having an ultimate destination in mind is vital.  Even if you're wrong, it's better to have one in mind that to have nothing.

Don't believe me?  OK.  Let's talk about what happens when you don't have a strategic context:

1. Team dissonance.  Ever been on a team that is not aligned?  Ever been in a meeting where everyone is arguing and nobody can even agree what they're arguing about?  On what basis are we trying to make a decision?  It's very frustrating.  Team members will not perform at their peak with high levels of team dissonance.
2. No clear decision criteria.  Without clear strategic goals, how do you make decisions?  What criteria do you use?  Not every decision has a strategic impact, but they all should be made in a strategic context so you can decide HOW to make the decision.  What factors will you use to weigh your options?  These are all strategic context issues.
3. Duplicative or contradictory work.  If your destination is unclear, how do you minimize the amount of repetitive or unnecessary work that gets done?  Being able to decide what NOT TO DO is usually way more important (and more difficult) than deciding what TO DO.
4. Multiple, conflicting agendas.  Whether overt or covert, people will develop their own plan.  Nobody likes wandering around in circles.  Without a clearly defined joint strategic context, the team members will start establishing their own vision.  The better the team, the worse this problem gets.  Smart people will figure it out but they won't always come to the same conclusion. 

So, how do we establish a strategic context?

There is no one single way to get this done.  In the end, all that matters is that you have a shared long term vision amongst the team members.  You can spend a week in a conference room or go build teepees in the desert together (and yes, I actually did that once; not recommended).  However you get there, you need to have a single unified vision of your long term future together.

This really only works if you are the team leader or you have great support from your leadership.  You cannot "manage up" on strategy.  Here are some tricks that I've used with various teams I've worked with in the past.

1. This is your strategy.  It has to work for you and your style.  You can hire a consultant to help with the process, but you cannot get strategy from other people.  Just doesn't work.  Most of the folks who hired me to be a strategy consultant ultimately failed because they really didn't believe in or accept what I was telling them.  In the end, I realized that my job was more like a AA leader.  They have to want to change.
2. Strategy is a living thing.  Don't waste time on long winded reports or white papers.  I really prefer PPTs, but that's just me.  Do what works for you.  However, you really need to think of your strategy as the group's shared vision, not the paper or document.  That's just an artifact.  A point in time that you use to explain it to others.  The point of strategic context is to get the team aligned, not to produce fancy documents or presentations.
3. This is an in person, touchy feely thing.  You cannot get a highly distributed team aligned to a group strategy or vision.  I have NEVER seen this work.  NEVER.  Get the team together, work as a group for as long as it takes.  Meet regularly to ensure that you're still on target.  Go get drunk together.  I have made more progress on this issue over beers after some trade show than I have ever done during a WebEx with guys from all over the world.
4. This is about passion, not reason.  Highly talented people are passionate about what they do.  This means that they form emotional attachments to their work products.  You need to recognize that.  Allow them to vent that emotion when their pet project gets de-funded.  Dissent within the team is awesome while you are discussing what you should do.  Once the call is made, then it's time to get with the program or get lost.  Your team needs to understand that it's OK to bitch or complain within these sessions but that it's not OK to be off message externally.
5. Interview your team.  Take time to sit down with each member of your team individually.  Ask them to explain the team's long term goals.  If they can't do it, you've failed to achieve strategic context for them.  Keep in mind that this is your failure, not their failure.  Explain the goals and reset.  Repeat this process at least quarterly.  Ask yourself if the goals are correct.  If your own team doesn't get it, will anyone else?

I wish you good luck in your journey.

ITA

An Open Letter To MSFT's New CEO

Dear Sir or Madame:

Congratulations on your new job as the CEO!  Microsoft is an amazing company and I truly wish you all the best.

As a twelve year veteran (1996-2008) of MSFT, I still consider my self a "softie" even though I've been gone for quite some time.  In point of fact, I still consider "My Microsoft" to be the way the company was in the late '90's.  The shambling wreck of a technology powerhouse that existed when I left really wasn't the company that I joined.

And that's a shame...

The reality is that Microsoft, like so many other proud companies has lost her way over the years.  Instead of the amazingly innovative "take no prisoners" company that I joined in 1996, the current company is overly bureaucratic, slow and boring.  Honestly, today's Microsoft feels more like IBM or HP.

Here are just a few things that have changed over the years:

1)  The stock was doubling every 18 months.  The reality is that kind of stock growth is unsustainable and everyone knows that.  However, it went on for many years and it really drove our culture.  We were willing to work hard and make personal sacrifices because we knew we were going to be rewarded if things went well.

2)  It was a true "meritocracy."  I know that this has been debated and discussed many times, but I was there and I can honestly say that you rose based on your merits.  Everyone in the company was stack ranked and I always knew where I stood.  It was brutal, competitive and perhaps not the most "nurturing" of environments but it make us stronger and leaner than our competitors.  

3)  We were empowered.  Everyone was way to busy to go and ask permission to do the right thing.  As a new employee, I actually sent a mail to my director asking if I should violate policy to help my customer with a particular bug they were experiencing (I wanted to give them a dev build to see if that fixed the problem which was not normally allowed).  The answer I got back was very short:  "Why are you asking me for permission to do the right thing?  Just do it and let me know if anyone tries to stop you."

4)  We were relentless.  It really didn't matter who tried to compete with us, we were young and arrogant and we knew we could beat them.  Whether it was Novell, Netscape or Lotus.  We were better than them and we knew it.  Naturally, that wasn't actually true but we had a swagger that allowed us to "punch above our weight."  Note that those guys are mostly gone or out of the enterprise software business (yes, I'm aware that IBM is still around but when was the last time you saw someone using Lotus Notes or 123 for God's sake?).

Ah, the good old days.

Well, that's not going to come back.  And honestly, most people would be aghast at the idea that MSFT might start acting like the arrogant bully that we used to be.  Honestly, I don't know if it would even be possible to remake the company like it used to be and I don't think it would be desirable either.

On the other hand.....

There are tons of things that Microsoft can and should do RIGHT NOW to kick some butt and regain your luster.

1)  Double down on Skype.  The really amazing thing to me is that I still have a phone on my desk.  Do you have any idea how silly that is?  Buying Skype was one of the smartest things Steve ever did.  You should make "Skype for Business" by immediately merging Skype and Lync.  Then sell the crap out of it for peanuts.  Kill off all the existing VOIP players.  The PBX guys are on their last legs anyway.  The thing that makes Lync struggle is PSTN connectivity.  That should be automatic.  Enter your credit card and your Lync server is instantly a Skype gateway to the PSTN.  Similarly, there is no reason why my Lync client can't connect to the Skype backend, right?  No more PBX.  Make "Lync For Business" free with Office 365 and then charge for the PSTN gateway only.  OMG.

2)  Become a VC.  Take that massive cash hoard and become your own VC.  Fund interesting guys to write apps for Windows Phone, Azure and .NET.  Yes, I know you're doing that now, but I'm talking about taking ALL OF IT and spending it on your platform.  Holy Crap.  That would terrorize Amazon!  Then you can buy the interesting and successful ones and add them to the MSFT family.  The reality is that you're way to big to do that kind of innovation in house.  No problem, just seed some cash and let others do it for you!  Yes, most of these ventures will fail, but if a real VC can make a profit doing it then you can also.  For that matter, just hire Fred Wilson or someone else amazing to run it.

3)  Bring back the stack rank.  People love to complain about the stack ranking system.  However, it was this culture of extreme competition within MSFT that made the company great.  MSFT will never be a touchy feely company like Netflix.  That's OK.  Go with your strength.  Think Tina Fey when she said "Bitch is the new black." 

4)  Don't buy Blackberry.  For God's sake.   Just don't do it.  Hardware is a chump's game.  Besides, Blackberry does zero to help you compete with iPhone and Android.  Ask the sidekick guys about that.

5)  Kill off the windows hawks.  Windows has too much power in the organization.  You need to allow office and other divisions to make money on other platforms.  Office for iOS is OK, but it feels like it was intentionally crippled to keep the windows guys happy.  Let them off the leash.  Make every division give you a plan for multi-platform in mobile or just fire up a whole new mobile apps team that's separate from the platform team.  Give them a goal of being the #1 ISV on both Android and iOS.  MSFT was the #1 ISV on the Mac years ago.  No reason why you can't do it again.


That's all you get for free.  If you want more, I do consulting at pretty reasonable rates.

Enjoy your new job!!  I'm sure it will be a rough ride.

ITA

The Four Types of Jobs

In a great article, Lou Adler argues that there are really only four job types in the world.  He describes them like this:

Everything starts with an idea. This is the first of the four jobs – the Thinkers. Builders convert these ideas into reality. This the second job. Improvers make this reality better. This is the third job. Producers do the work over and over again, delivering quality goods and services to the company’s customers in a repeatable manner. This is the fourth job. And then the process begins again with new ideas and new ways of doing business being developed as the old ones become stale.

If we apply this taxonomy to the Architect Role, we can very quickly see how the “thinker” role seems to apply.  However, he also states that most jobs are some combination of these with one or two of them being predominant.  In our case, it seems pretty clear that the Architect role is a combination of Thinkers and Builders.  In fact, while interviewing architects for this book, I realized that the variation of architects and how they view their role is largely a display of these two factors playing out.  By having more of one than the other, you get the various types of architects that we tend to see in our lives:

 

·         The hand waver (100% thinker, 0% builder).    We all know architects who are really good on the whiteboard, but can’t actually make anything.  My bias is that this type of architect is not useful because no value gets produced by them directly.  This is perhaps unfair because extremely complex systems need people who are 100% thinkers to get the abstractions and concepts right.

·         The Visionary (75% thinker, 25% builder).  This person is really bright and sees the future clearly.  However, their light builder bias means that although they’re aware of reality, they’re not really bound by it.  Think Steve Jobs.  While this model is worshiped in Silicon Valley, it turns out that these folks have limited utility.  You only need one visionary in your org, right?

·         The Far Seer  (50% thinker, 50% builder).  This person usually has an operational or dev background.  They have vision but it’s firmly grounded in reality.  It’s tougher for these types of architects to invent new paradigms but they’re really good at figuring out N+1 or N+2.

·         The “Gets Shit Done” (25% thinker, 75% builder).  This is the guy who simply gets it done.  Give them a sort spec sheet and you see them go to the white board right away.  A few hours later, you’re getting functional diagrams and then code shortly thereafter.  They’re probably building their own prototypes.  This type of architect works really well in a small shop and in agile style dev organizations.

·         The Principal Engineer (0% thinker, 100% builder).  This guy is an architect in name only.  Perhaps they rose up from the eng organization or is the most senior guy on the team.  Just because you can code rings around everyone else on the planet, does not make you an architect.  Sorry.

You may want to apply these metrics to yourself.  What percentage of your intellect do you apply to the thinker or builder side of the equation?  When you work with other architects, how do they align to this continuum? 

Personally, I find myself somewhere between the Far Seer and the Visionary.  I’m no Steve Jobs, but I’m usually comfortable thinking about complex abstract problems.  However, I also like getting my hands dirty.  So, I fall somewhere in-between.

Are you a Cop or are you the entertainment?

'Cause you can't be both.

One thing I hear all the time from IT organizations is that they are seeking to become services organizations.  They want to be an internal service provider or a "valued service provider."  I think that this is a very good thing and I always encourage my customers to take this direction if possible.

Unfortunately, what usually comes next is "and of course, we will need to maintain security standards and best practices."  Whoops.  That's not going to work.

If you think about people you do business with, they're usually folks that you like and you want to do business with.  Unless they're a monopoly like the cable company.  If you had a viable alternative to cable, would you take it?  Probably.  Nobody likes the cable company.  That's because you're forced to do business with them.  That type of relationship doesn't really end well once a viable alternative shows up.

Same thing with transforming your IT organization.  If your goal is to provide a very high level of service to your internal customers, you can't do that by telling them what NOT to do.  Think about it.  You don't invite the police to your party to help your guests have a good time, right?  Not that there's anything wrong with the cops, but they're definitely in the business of telling you what not to do.  They are not there to entertain you or help you have a good time.  No, you hire entertainers at the party and hope the cops don't show up.

How does this relate to IT?  

I think that we need to recognize that as an IT organization, we are in an impossible position when we attempt to both enforce rules and behave as a customer centric services organization.  In reality, no one organization can do both successfully.  I have never seen it done.  I'd be happy to be wrong here, please let me know if you have ever seen this done well.

My recommendation here is to split the function.  A small security and compliance function under the CFO along with all the other audit functions and a customer service organization under the COO.  This allows the two facets of IT to do their things without expecting the cops to sing and dance.

In the meantime, please check out my new "Masters Series" videos.  This blog post was inspired by my Masters Series interview with Alan Hakimi.  If you're an Architecture geek like I am, these videos are fascinating glimpses of how architects work.  Enjoy.

http://bit.ly/ajmasters

The 5% Solution?

I don't usually deal in absolutes.  The traditional consulting answer to any question is always "it depends."

However, in this case, I'm going to propose a rule.  Or perhaps as in "Pirates of the Carribian" it's more like a guideline.

"Never commit more than 5% of IT resources to any one project."

Perhaps we should refer to this as "Jauch's Law of IT Portfolios."

As loyal readers know, I'm a big fan of IT Portfolio management.  For those new to the program, this concept basically says that IT is just like any other investment.  You must balance your risk and actively manage your investments to maximize your return. 

This philosophy has some additional parallels.  I'm sure that any decent financial advisor will tell you to spread out your risk.  Not to get too deep into any one investment.  The same thing goes for IT.  For IT shops that are managing their IT portfolio, this rule is something to consider also.

If you are looking at overall IT resources and a single project starts sucking up more than 3 or 4 percent of total resources, you should be carefully considering that investment.  By committing, say, 10% of IT resources you are basically saying that your company is going to live or die based on the outcome.  A major failure in such a large project will be difficult to recover from.

This is an interesting reason why SaaS is so interesting.  By reducing capital outlay and spreading out payment to a vendor (basically a leasing scheme rather than outright purchase) SaaS has the side effect of pushing not only cost but also risk into the future.  Normally, SaaS can reduce the amount of internal labor required also because you don't need to build out your own infrastructure.

Does this mean that SaaS is good all the time?  Not at all.  Remember, that you want to have a broad portfolio.  Spending all your money on SaaS doesn't make any more sense that spending all your money on a huge SAP installation.  It's all about balance.

Don't Be Lazy. Create Value!

It's funny how cyclical the technology business is.  I guess that's not surprising since humans do tend to make the same mistakes over and over.  You would think that the rapid cycle time of our business would mean that folks haven't forgotten the old mistakes before making them again.  However, reality keeps proving me wrong again and again.

In this case, the failure is one of cost savings vs. value creation:

http://gigaom.com/2013/04/11/cloud-adoption-its-not-about-the-price-stupid/

I cannot tell you how many times I have seen companies chase the cost savings rabbit down the customer rabbit hole.  In the end, this strategy almost never works.  Eventually, you have to go back to the actual reason why you are in business:  to create value for your customers.

I'm not trying to say that cost cutting doesn't work.  Clearly, it does.  Just look at Walmart.  However, we are not talking about retail here.  In the technology business, we are not operating in an efficient commodity marketplace.  The object of our game is to create customer value by delivering IP in the form of technology.  Retail transactions are about providing the exact same goods to the consumer.  You really can't innovate much there.  It's about price, convenience and service.  This is not the business that we are in.

Perhaps some day the pace of innovation in the IT marketplace will slow down to the point where we're basically all selling the same thing but we're not there yet.

In the meantime, you really need to be focused on value and the customer's perception of your product's value to them.  If you can do this successfully then you will do well overall.

I've discussed this topic in the blog before, but for those who are new to this blog, you really should check out Mahan Khalsa's book:  "Lets Get Real or Let's Not Play."  Highly recommended even if you're even marginally involved with talking to customers.  As a non-sales guy, it's easy to think of sales as sleazy or icky in that used care salesman kind of way.  And this is a sad thing.  The reality is that most sales people suck.  It's only when you're in the presence of a highly functional sales team that you realize how powerful it can be to transform your customer's lives.

If you take Khalsa's precepts to heart, then your function is always to seek the customers needs (as opposed to their stated desires or wants) and then to satisfy those needs.  If the customer relationship is focused on this very important transaction, it becomes a very positive experience for everyone.

Thus, short term strategies like selling based on a largely fictional TCO reduction don't really work.

How IT Can Stay Relevant

Interesting discussion today about IT relevance in the modern cloud era:

http://gigaom.com/2013/03/31/technology-is-king-so-why-are-so-many-it-departments-playing-backseat-roles/?go_commented=1#comment-1324633

As pointed out in the comments section, this is definitely a topic that’s been discussed at length.

I would argue that the discussion goes back much farther than most realize. My first job in IT was part of a “shadow” IT organization. Our job was to help the business deploy technology that was readily available on the open market but that IT was not willing to provide for us.

Except that this was in 1989 and the technology was Macintosh computers.

As I wrote in my book "Why We Fail" this is part of a larger struggle between IT as a source of control for the organization and IT as a service provider. You cannot do both well.  In many cases, IT organizations feel it is their responsibility to control technology to protect the organization from it's internal users.  While this is a valid concern, it does not promote a culture of service that is required for IT to remain relevant.

I strongly believe that IT must transform into a customer centric model to help drive businesses forward.   Consider the chart below:

 

Traditional IT	Customer Centric IT
Sets IT Standards	Supports Business Requirements
Focus on Operations Excellence	Focus on Customer Satisfaction
Engineering is key skill set	Consulting is key skill set
Sets Policy	Seeks Input
Focus on Large Projects	Focus on Smaller Projects
Organized by Technology	Organized by Customer
Technology Focus	Business Value Focus
Delivers most projects in house	Brokers external vendors as needed

 

Customer centric IT organizations do not seek to set or enforce policy.  Rather, they seek input and they are organized around the customer.  It is the focus on the customer's needs that ensures that a customer focused IT organization will remain relevant in a modern cloud era.

Four Architectural Tenets

Similar to other IT functions, it can often be difficult to understand the value of IT architecture and to make the case for strong architectural practice.  When you add solutions as an additional layer of abstraction, this is even more difficult.  In one sense, you are getting further away from technology and therefore more theoretical.

However, in the case of solutions orientation, this added abstraction is done for a very pragmatic reason.  Solutions based engineering allows us to be closer to our end customer.  This is true whether you work in an IT organization or within a product group at a software company.  Our solutions orientation should make it simpler to show the business case for architecture, rather than harder.  Unfortunately, this is not true for many traditional Enterprise Architecture disciplines.  This is not to say that these disciplines have no value.  Not at all.  However, they are abstractions intended to help the technical team order complexity in a way that allows them to design a very complex system.  To the end user or customer, these complex systems are only of a passing interest.  Thus, like a hammer or a nail gun, they should be used only when necessary.  If the architecture framework is making your life as an architect better and allowing you to deliver solutions more quickly, then they’re good.  If they’re slowing you down, they’re bad.

If we are to claim that architecture has value, we need to establish the core tenets of what a "good" architecture is.  This is something that not all architects take into consideration when building projects or systems.  For example, speed of execution is just one benefit of the core architecture tenet I call Simplicity.  There are tons of different ways of expressing core tenets, but to me they all boil down to four basic tenets:

 

I like to express this as a Venn diagram because I feel that when I design something, there is a huge attack surface of any project.  However, the best design is a relatively small point where the Venn diagram overlaps.  Sometimes, it feels like the circles are the size of football fields and the overlap is the size of a postage stamp.  Being the eternal optimist, I insist that there must be an overlap someplace and that I just need to find it.

Core Architecture Tenets

 

·         Simplicity.  Simplicity of design is something than transcends IT.  By definition, the simplest solution that meets all the design criteria is the best design.  Complexity is the enemy.  This is true for many reasons (speed, maintenance, esthetics, etc.)

·         Alignment.   However, the solution needs to be aligned to the requirements of the business.  If the technical solution does not solve the stated problem, what’s the point?  You need to hit your requirements or the design is fundamentally flawed.

·         Quality.  Something that is done poorly is best not done at all.  It’s always easier to do something poorly.  However, I don’t think any of us actually aspire to produce poor results.  This is true for architecture just as it’s true for development or deployments.

·         Future Ready.  One thing we can be certain of in our business is change.  Whatever we build will need to be modified going forward.  Unlike things like cars, our designs will most likely be upgraded several times over their lifetimes.  Good architectures take this into account and allow for future changes.

The Death of Loyalty

In modern American business, the idea of loyalty is pretty much dead.

In years past, there was a sense that employees owed a certain amount of loyalty to the firm and in turn they expected this loyalty to be rewarded by security, advancement and compensation.  Companies would invest in their people through training and development activities that made those employees more valuable in the long term.

This virtuous cycle seems to be pretty much dead today.

In today's reality, certainly in the quickly changing high tech sector where I live, there is very little expectation that the company will "take care of you."  Yes, the probably will provide training but usually that training is focused on short term goals.  There are very few companies in Silicon Valley today who make a sincere effort to develop their technical people and actively manage their careers.

I started my career in an "Old Fashioned" company that had all the traditional trappings of employee development.  Because of this, I benefited in the type of developmental planning and support so crucial to help junior technical people enter the workforce.  Later in my career I actually ran a large professional developmental program designed to create Architects from engineers.

Today, as I look around and consult with my peers, these programs are markedly absent.  I am aware of no major Silicon Valley companies actively developing Architects within their organizations. 

BTW, I would love to be wrong here.  Please let me know in the comments if you're aware of any company doing this kind of work.

So, if this type of development isn't being done by our employers, how are we going to develop ourselves and the next generation of architects?

I've come to the realization that we must do this ourselves.  It is only through community that we can address this problem.  This is one reason why I decided to start writing books.  Not that I think my books will move an industry but rather that I need to share my experiences and learning's.  If one person is helped by this then I feel the effort of putting ideas down on paper was useful.

I have also recently been trolling the Linkedin universe to see if this is a good place for this type of professional development.  As of what I see today, the signal to noise ratio is just too high there to be useful.  Linkedin, as a platform, is awesome for keeping tabs on what everyone is doing and I love it for that purpose.  However, as a learning tool, it's too uncontrolled and too open to be useful.  What's needed here is curation.  A hiking trail that says "start here and end there."

Again, to my knowledge such a thing does not exist.  I definitely welcome postings in the comments section telling me how incredibly wrong I am!

In the meantime, I strongly encourage you to think about how you are helping the Architects in your organization develop.  Mentoring and OJT are our only options right now and that requires effort for those of us already in the profession.