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.

Private Cloud Matures: The Suits Take Over?

Like many things in life, new technologies have a distinct life cycle that is somewhat predictable.  The pace at which they move through this life cycle usually isn't predictable and they sometimes simply fail to progress along the life cycle, but the sequence of events usually predictable even if the pace of this transition is not.

In the private cloud world, there is so much hype and so much pent up market demand that it seems obvious that it will proceed along this timeline fairly rapidly.  However, this is a pretty major paradigm shift so the pacing is difficult to predict.  Because of this, I'm always on the lookout for actual data that shows progress (or lack thereof) in this space.  Recently, CapGemini has come out with a great study that shows that this progression is moving along rapidly:

http://www.capgemini.com/insights-and-resources/by-publication/business-cloud-the-state-of-play-shifts-rapidly/

In short, the study says that Cloud deployment decisions are largely being made by business leaders instead of technology leaders.  That's not unusual when a technology matures.  It's also interesting that in this sample, cloud is becoming very ubiquitous.  This also lends credence to the idea that Cloud is now mainstream and moving into a mature technology phase.

The other interesting thing in this study is the very high percentage of folks who are stating cost savings as a reason to move to cloud.  51% state that cost savings is a major driver for cloud. However, other post-deployment studies have shown that cost savings from cloud aren’t that significant (like this one from CSC). There seems to be a growing gap between expected benefit and actual benefit. Given all the hype, this isn’t unexpected but it may lead to the collapse of the hype cycle.

We have seen this movie before.  When distributing computing started to become mainstream in the early '90's the same thing happened.  This was supposed to enhance productivity and have a positive ROI.  In actual practice, this didn't happen.  Organizations who had loose management policies found little or no financial benefit.  The implementation of distributed computing on it's own had little or no financial benefit.  It was the change in business process that led to benefit, the technology was simply an enabler of this.

The same thing is happening here.  Companies focused on benefits management can gain significant business advantage in deploying cloud style architectures.  However, there is no inherent benefit in cloud. 

Be a CIO in Three Easy Steps

Read a blog post today that made me laugh:

http://www.zdnet.com/why-cio-success-comes-down-to-just-three-things-7000006850/

Basically, the thrust of the post was that a CIO only has to do three things:

1. Eliminate risk
2. Improve cycle times
3. Reduce cost

And if you read the post, then those three things really come down to one thing:  Converged Architecture.  After reading the article, I'm pretty sure the author either works for a converged architecture vendor or just spent a huge sum of money on a new converged architecture system.

Being an Ex-Vendor of converged architectures myself, I do like the idea that converged architectures solve everything.  Unfortunately, this just ain't true.  Sigh.

I also have a funny feeling that being a CIO comes down to more than just three things.  To be fair, it's more than just a feeling.  I used to run a CIO consulting program for Microsoft so I've spent quite a bit of time working with, supporting and selling to CIO's.  I've spent a good portion of my life thinking about this position and what it takes to be good at it.

However, I do like this list as a conversation starter.  If I was a CIO, I would definately be thinking about these three things.  They're probably even in the right order.  If you don't have your risks addressed, then reducing cost and improving cycle times don't matter much.

On the other hand, the blog post really misses a great opportunity when discussing risk.  Risk is one of those things that seems to be widely mis-understood in the technical community.  To me risk is not good or bad.   Eliminating all risk is not really possible nor is it desirable in most cases.  Risk is something that needs to be managed, like the weather.  As they say in the Pacific Northwest, there is no such thing as bad weather, just insufficient gear.  That's probably not strictly true, look at what our friends in the NorthEast are dealing with due to Sandy.  The fact remains that weather must be dealt with and managed.  We cannot control it just like we cannot truly control other sources of risk.

To change the saying to our purposes, let's just say that there is no such thing as a bad risk, just insufficient planning for that risk.

When thinking about risk, we must first think about our sources of risk.  These may be business (the company is loosing money and fires half of IT) or Technical (the main router blows a power supply) but they also may be political (the city of New York declares your business model illegal; yes I'm talking to you Uber) or natural (Sandy puts your DC under ten feet of water).  Under no circumstances can you do any one thing to manage all these sources of risk.

The next thing to consider is risk mitigation.  What can I do to make this source of risk less likely to actually occur?  In many cases, a strong mitigation plan can completely eliminate a source of risk.  Having no single point of failure in a DC is a common example of this type of risk planning.  However, this is not the best choice in all cases.  For example, what happens if the object being protected is basically a throw away object?

This leads us to contingency planning.  In some cases, it's simpler and easier to simply mitigate the risk once it occurs instead of making the risk less likely to occur.  For example, I used to back up my laptop once a week.  Honestly, it was a pain in the butt and I didn't remember every week.  Now, I used a cloud based storage platform (SkyDrive in my case) so there's nothing on my laptop that's not replicated to the cloud.  No need to backup any more.  If the laptop dies, then it dies.  No data is lost.  Should I bother spending huge amounts of time on keeping my laptop healthy?  No.  Should I bother buying a second hard drive to mirror my local drive?  No.  There is no point.

When deciding which sources of risk to focus on, think about the probability that the risk will occur multiplied by the business impact (measured in dollars).  The risks with the highest probability and the highest impact are naturally more important than those with relatively small impact or extremely low probability.  Unlike the blog post above, there is no way you can afford to completely mitigate all risk.  You can reduce your risk profile but you cannot take it down to zero.