Archive for the ‘inside-out IT’ Category

Running IT as a business: don’t be daft

Thursday, January 21st, 2010

In the past couple of days I’ve read a couple of articles (”IT can’t be a service provider and a partner too” and “Run IT as a business – why that’s a train wreck waiting to happen“) that riff on the same theme: that the exhortation to “run IT as a business” leads you down a road to organisational exile.

Put briefly, the thinking seems to be: if you set an IT organisation up to run as a business, you create a supplier-customer relationship with other parts of your wider organisation – and this relegates you to being a simple order taker. You’ll have to implement the requirements you’re given, and often these will be out of whack with what the organisation will really need and will raise IT costs over the long term, making an internal IT operation even less attractive and making you more likely to be outsourced.

In my experience this analysis is plain wrong, and comes from simplistic thinking about what the phrase “run X as a business” might mean. Being more business-focused has multiple facets to it, and blindly interpreting the idea leads you to daft, simplistic conclusions. Applying similar thinking to cooking would lead to the advice “don’t use sharp knives; if you do that it’ll only be a matter of time before you chop a hand off”.

To be clear: my experience and advice diverges with these other opinions not because I disagree about the risks of IT becoming a “simple order-taker”; but rather because I disagree that running IT as a business means you have to become a simple order-taker and everything else is excluded. There’s much more to it than that. The key is to see the relationship between IT and other areas of a business as having three key layers.

When I look at IT leaders who have really become strategic players at board level (and I’ve been talking to them ever since my work on The Technology Garden), it’s not the case that their organisations have stopped becoming service-focused and focus wholly on hanging out with senior business managers. If anything their organisations are more service-focused than the norm.

In the best-performing organisations, the “run IT as a business” idea is primarily about an inward-looking perspective. It’s about putting repeatable processes in place, creating a service culture, figuring out the actual costs of delivering IT services through IT processes, and looking for ways to increase IT process efficiency and effectiveness.

In high-performing IT organisations, when it comes to the outward-looking perspective (the relationship between the IT organisation and other parts of a business) the relationship has at least three layers:

  1. As a foundation, IT teams have to deliver reliable operational services in line with clear promises and in the context of defined cost expectations and budgets.
  2. When it comes to using IT to enable business in new ways the relationship works at a higher level, using different teams, reporting structures, skills and incentives within multidisciplinary joint IT-business teams.
  3. The top layer acts to mitigate the risks of individual business units driving change that is counterproductive to the organisation as a whole, typically through some kind of IT governance structure that helps to ensure that significant IT investments are considered in their proper strategic context and that the costs and risks are properly understood by all.

That’s three layers: IT operation/service delivery; IT-business engagement; and governance/strategy. You can be focused on service provision and also on partnering. As long as you understand the bigger picture.

Posted in alignment, architecture, governance, inside-out IT, outsourcing | 2 Comments »

Businesses aren't machines, and enterprise architecture can't make them so

Wednesday, July 23rd, 2008

Via Service Oriented Enterprise, I recently picked up an Infoworld blog post by SOA journeyman David Linthicum, where he makes a couple of very strange points about SOA and ESBs. It may be, of course, that the post is pure link bait: certainly, David appears to have said some relatively sane things in the past, so that might be it. If it is link bait, I’m going to fall for it now.

In his piece David quotes a representative from iTKO, who repeats the now well-understood insight that in some large organisations, there’s a challenge that arises because different groups with SOA initiatives find themselves having to integrate different ESBs in order to pull together implementations for cross-silo scenarios. He then goes on to comment (I’ve taken the liberty of extracting elements of his piece below):

First, if there is indeed ‘enterprise architecture’ and an ‘enterprise architect’ then the different divisions should not be using different ESBs, or even an ESB for that matter… Second, considering that my first point is correct (which it is), why the heck are you attempting to integrate these integration engines when they should perhaps be displaced altogether. Because, call me crazy again, that would be cheaper… just to be clear, you determine your requirements, and then the solutions patterns, and then the technology.

The most charitable explanation I can come up with for David’s position is that he believes passionately in the transformational power of enterprise architecture. The problem with this perspective is that even where EA is highly effective (and in many places it isn’t), it can at best only be one of many forces shaping the way that IT evolves to support changing business conditions and requirements, and each force has its own vector. Some forces, like a good EA team, try and combine business and technology focus, and promote the value of global optimisations, good practice and standardisation. But most of the most powerful forces are business forces, and in 99.99% of organisations, their power, when something really big and important happens, will trump any righteous splutterings emanating from IT departments.

As any experienced IT staffer who’s been on the sharp end of a big business merger or acquisition, or even a radical change of leadership, will tell you, businesses don’t act like machines that EAs can simply steer so that they tend towards technology optimisation. In fact, it’s the opposite: business change forces (new competitors, new product launches, new market launches, new regulations, mergers and acquisitions, and so on) will always drive entropy, tending to push IT estates towards chaos. The best value an EA team can really provide in this environment is to help the IT organisation to absorb these changes with as little stress as possible, and drive consistent, planned responses.

Still, there’s always been a vocal (and quite often technically brilliant) part of the IT industry that seems to misunderstand this, and persists in maintaining that once people see beautiful models, they’ll modify their behaviour to enable the models to be made real. They see businesses as deterministic machines that can be algorithmically decomposed, analysed, predicted, and shaped. I can only think that David is one of these people.

Unfortunately, no matter how clever your EA team might be, no amount of architecture astronautics can make businesses change their nature.

Posted in EA, ESB, SOA, inside-out IT | 3 Comments »

Rethinking IT projects? Think service, not product, focus

Thursday, September 27th, 2007

I’ve read a number of articles and thought pieces recently that explore the problems with approaches to IT delivery that focus too much on projects as the organising concept – particularly when it comes to SOA adoption. The shortcomings of an overly project-focused approach are something I can agree with wholeheartedly. The research we conducted for The Technology Garden (Wiley, 2007) convinced me that driving IT delivery using a project-focused organising principle is one of the worst things you can do if you want to try and increase the business value delivered from IT investments.

But if projects are passé, what should they be replaced with? Most of the commentary I’ve seen suggests that a better approach is to think as if you’re developing commercial software products. The excellent Todd Biske has one such piece here.

You have to be think carefully before diving deeply into a product management mentality, though. The trouble is that taking too literal a view of IT delivery through the lens of product management can prevent you from reflecting reality the way that “customers” (regular business people in your organisation, and quite possibly those external customers that ultimately pay all the salaries) see it.

Why? Because software products have no business value, no matter how well-managed the processes to create them were. Business value only comes when you implement a software product and get business results. A shrink-wrapped DVD by itself doesn’t get you any results, only a coaster for your coffee cup. Electronic software delivery doesn’t even get you a coaster – it just fills up your hard disks with useless ones and zeroes.

You have to wrap all kinds of IT services – install and config, integration, customisation, training, administration, user support and so on – to turn a product into something that delivers real business value to real business people. The interface that regular business people have with IT isn’t with products, it’s with IT services. Even Microsoft, the ultimate software shrink-wrapper, has realised that enterprise customers don’t buy products, they buy outcomes (see this old post for info).

That’s why the only way to deliver sustainable improvements in business value delivery is recognising that for the customers of IT organisations, “service is king”, and starting to organise IT delivery around that. The first obstacle to overcome is to find ways of bridging the incredibly harmful divide that so often separates software development teams from IT operations teams.

If you take too much of a product management centric view, the danger is that you focus all your energy creating the right kind of development and deployment capabilities, without thinking of the broader service experience that customers need and expect over the lifecycle of a long-term commitment. IT operations is where the rubber meets the road, and where customer expectations are met or dashed. Too simplistic a focus on product-style management for IT delivery perpetuates the development-operations divide and squanders a great opportunity.

Posted in governance, inside-out IT, sustainability | No Comments »

IBM to buy Telelogic: Rational, but not inspirational

Friday, June 15th, 2007

I know in the blogosphere, waiting a few days to provide comment on an announcement like this one hardly puts me at the leading edge – but hey. Although I can’t claim to be breaking any news, there are a couple of other points about IBM’s purchase of Telelogic that I think are worth making.

As many other commentators have explained, in one respect the purchase of Telelogic takes Rational back to its roots as a tools provider to assist with the development of embedded systems. In this respect, the purchase of Telelogic is really all about IBM capturing market share and consolidating the market for engineering tools for complex systems development. This analysis was given extra weight by comments made by Danny Sabbah, the General Manager of IBM’s Rational business, when he stressed that investment in Telelogic’s tools and capabilities would absolutely continue. If IBM keeps the commitment made by Danny Sabbah, Telelogic customers can breathe a sigh of relief, and so will IBM. Embedded software developers love their tools, and many Telelogic customers will have made an explicit decision in the past not to go with Rational.

When you look at this (the biggest) part of Telelogic’s business it’s clear that this isn’t just the usual story of mature markets consolidating, however. Back in 1999 I spent more months than I care to remember on this project, which convinced me it was only a matter of time before ubiquitous broadband networking, consumer electronics and the digitisation of content would open up major new markets for tools vendors. The “pervasive computing and content” thing is starting to happen in earnest, in a variety of sectors – including automotive, healthcare, consumer electronics, retail and travel. Where these things come together, consumer-friendly (and that means high-performance, highly-reliable, bulletproof) software is appearing in more places and in more guises. This is new market opportunity, and Telelogic gives IBM the chance to grab more of it.

So far, so Rational.

But what’s been more interesting of late, to me at least, is not Rational’s heritage but it’s future direction. IBM has made it clear that Rational’s focus is shifting from being a provider of development tools to being a provider of tools to help manage the process of software delivery – and helping customers turn IT inside-out. A big gap here has been in the provision of tools that really help customers model above the level of individual systems, and the surprise to me has been that although Telelogic has these (obtained when it bought Popkin back in 2005) IBM’s early talk hasn’t put much emphasis on their value. To me this is a major missed opportunity as it’s a capability that more and more “mainstream” businesses with IT organisations are starting to realise that they need. Enterprise Architecture competency is quite thin on the ground and IBM has a chance to take a significant step forward in guiding customers here.

Assuming IBM does start to think and talk a bit more about Telelogic’s enterprise modelling tools (which would seem to make sense, you’d think) my take is that this is one area where the technology would be best served within Rational’s own product management structure rather than under Telelogic. As Rational moves its focus more towards managing the process of software development, the Telelogic assets naturally form a specialised sub-piece within the overall picture – but System Architect fits naturally alongside things like RAM, RMC, RPM, and some other stuff I can’t talk about yet.

So – I really hope we start to see more from IBM about how the more mainstream capabilities of Telelogic will be taken forward, and if/how it will start to separate those mainstream capabilities from the specialist “complex systems engineering” capabilities.

Posted in EA, Telelogic, acquisition, architecture, ibm, inside-out IT | No Comments »

Turning IT inside out and the trouble with ITSM and BSM

Monday, June 4th, 2007

The other day Martin Atherton over at our partner Freeform Dynamics got me thinking again about the IT service management (ITSM) / application management / business service management (BSM) hoopla we’ve long been saddled with in the IT industry.

I can absolutely see why vendors would want to try and avoid being seen as “just” providers of ITSM tools and make themselves look more “businessy”. It’s another example of the stack race phenomenon you see in so many areas – development tools, middleware, etc – and the simple idea is that if you can make your offering look and sound as if it can help customers talk more effectively to businesspeople, it’s better than an offering that is a bit oily under the fingernails.

And I absolutely believe there’s a place for tools that can help customers explain the value of IT investments in a way that makes sense to the people who pay the bills.

The problem is that the vast majority of the technology and practice out there does nothing of the sort – at least not without the expenditure of a lot of blood, sweat and tears. To characterise the ITSM/app management/BSM “stack” probably crassly unfairly, all that happens as you move higher up the stack is that events and alerts are correlated at ever more abstract levels. Events from routers, servers and switches are aggregated to give higher-level views of health and performance of infrastructure; infrastructure events are correlated with stats from DBMS instances, application servers, web servers and more to give higher-level views of health and performance of “applications”; and information at the application level can sometimes be aggregated further.

But fundamentally all we’re doing is reporting on more chunky technology outcomes. The outcomes we’re reporting on are still technology outcomes. The insight is about performance, uptime, security, and so on. There is no business context.

I could argue that we do have technology that can help provide business context to ITSM, app management and BSM – business activity monitoring (BAM). But to focus first on technology is missing the point.

The real underlying point is that do really manage services that make sense in a business context, the whole mindset of the IT organisation has to be turned inside out. IT organisations have to stop focusing so much on internal perspectives of process improvement and efficiency (are we doing things right?), and start focusing a bit more on a more external perspective (are we doing the right things?)

To pursue this idea of “inside out IT” into the software development realm, let’s not forget – as I said to an audience of CIOs last night: you can be at CMMi level x and still not guarantee that the things you do will drive business value; instead you *can* turn out irrelevant systems, but in a very predictable way.

Posted in BSM, ITSM, inside-out IT, methods, tools | 2 Comments »