enterprise architecture

You are currently browsing articles tagged enterprise architecture.

The IT department we have today is not the IT department we’ll need tomorrow

2010/04/21 in Business-Technology, IT Strategy, Mailing List by peg | View Comments

The IT departments many of us work in today (either as an employee or consultant) are often the result of thirty or more years of diligent labour. These departments are designed, optimised even, to create IT estates populated with large, expensive applications. Unfortunately these departments are also looking a lot like dinosaurs: large, slow and altogether unsuited for the the new normal. The challenge is to reconfigure our departments, transforming them from asset management functions into business (or business-technology) optimisation engines. This transformation should be a keen interest for all of us, as it’s going to drive a dramatic change in staffing profiles which will, in turn, effect our own jobs in the no so distant future.

Delivering large IT solutions is a tricky business. They’re big. They’re expensive. And the projects to create them go off the rails more often than we’d like to admit. IT departments have been built to minimise the risks associated with delivering and operating these applications. This means governance, and usually quite a lot of it. Departments which started off as small scale engineering functions soon picked up an administrative layer responsible to the mechanics of governance.

More recently we’ve been confronted with the challenge with managing the dependancies and interactions between IT applications. Initiatives like straight-through processing require us to take a holistic, rather than a pieces-parts, approach, and we’re all dealing with the problem of having one of each application or middleware product, as well as a few we brewed in the back room ourselves. Planning the operation and evolution of the IT estate became more important, and we picked up an enterprise architecture capability to manage the evolution of our IT estate.

It’s common to visualise these various departmental functions and roles as a triangle (or a pyramid, if you prefer). At the bottom we have engineering: the developers and other technical personnel who do the actual work to build and maintain our applications. Next layer up is governance, the project and operational administrators who schedule the work and check that it’s done to spec. Second from the top are the planners, the architects responsible for shaping the work to be done as well as acting as design authority. Capping of the triangle (or pyramid) is the IT leadership team who decide what should be done.

The departmental skills triangle

While specific techniques and technologies might come and go, the overall composition of the triangle has remained the same. From the sixties and seventies through to even quite recently, we’ve staffed our IT departments with many technical doers, a few less administrators, a smaller planning team, and a small IT leadership group. The career path for most of us been a progression from the bottom layers – when we were fresh out of school – to the highest point in the triangle that we can manage.

The emergence of off-shore and outsourcing put a spanner in the works. We all understand the rational: migrate the more junior positions – the positions with the least direct (if any) contact with the business proper – to a cheaper country. Many companies under intense cost pressure broke the triangle in two, keeping the upper planning and decision roles, while pushing the majority of the manage and all the do roles out of the country, or even out of the company.

Our first attempt at out-sourcing

Ignoring whether or not this drive to externalise the lower roles provided the expected savings or not, what it did do is break the career ladder for IT staff. Where does you next generation of senior IT personnel come from if you’ve pushed the lower ranks out of the business? Many companies found themselves with an awkward skills shortage a few years into an outsourcing / off-shore arrangement, as they were no longer able to train or promote senior personnel to replace those who were leaving through natural attrition.

The solution to this was to change how we brake-up the skills triangle; rather than a simple horizontal cut, we took a slice down the side. Retaining a portion of all skills in-house allows companies provide a career path and on the job training for their staff.

A second, improved, go at out-sourcing

A second, improved, go at out-sourcing

Many companies have tweaked this model, adding a bulge in the middle to provide a large enough resource pool to manage both internal projects, as well as those run by out-sourced and off-shore resources.

Factoring in the effort required to manage out-sourced projects

Factoring in the effort required to manage out-sourced projects

This model is now common in a lot of large companies, and it has served us well. However, the world has a funny habit of changing just when you’ve everything working smoothly.

The recent global financial criss has fundamentally changed the business landscape. We are experiencing not merely another turn of the business cycle, but a restructuring of the economic order. Many are even talking about the emergence of a new normal. The impact this will have on how we run our businesses (and our IT departments) is still being discussed, but we can see the outline of this impact already.

Companies are becoming more focused, while leaning more heavily on partners and services companies (BPO, out-sourcers, consultants, and so on) to cover those areas of the business they don’t want to focus on. We can see this from the global companies who have effectively moved to a franchise model, though to the small end of town where startups are using on-line services such as Amazon S3, rather than building internal capabilities. While this trend might have initially started as a cost saving, most of the benefit is in management time saved, which can then be used to focus on more important issues. We’re all finding that the limiting factor in our business is management time, so being able to hand off the management of less important tasks can help provide that edge you need.

We’re also seeing faster business change: what used to take years now takes months, or even weeks. The constant value-chain optimisation we’ve been working on since the 70s has finally cumulated in product and regulatory life-cycles that change faster than we can keep up. Nowhere is this more evident than the regulated industries (finance, utilities …), where updates in government regulation has changed from a generational to a quarterly occurrence as governments attempt to use regulation change to steer the economic boat.

Money is also becoming (or has become) more expensive, causing companies and deals to operate with less leverage. This means that there is less capital available for major projects, pushing companies to favour renting over buying, as well as creating a preference for smaller, incremental change over the major business transformation of the past.

And finally, companies are starting to take a truly global outlook and operate as one cohesive business across the globe, rather than as a family of cloned business who operate more-or-less independently in each region.

We can draw a few general conclusions on the potential impact on IT departments of these trends.

  • The increase reliance on partners, the broader partner ecosystem this implies, and an increasingly global approach to business will create more complex operational environments, increasing the importance of planning the IT estate and steering a company’s IT in the right direction.
  • The need to reduce leverage, and free up working capital, is pushing companies toward BPO and SaaS solutions, rather than the traditional on-premisses solutions, where the solution provider is paid per-seat, or might even be only paid a success fee.
  • The need for rapid project turn-around is pushing us toward running large portfolios of small projects, rather than a small number of large projects.
  • A lot of the admin work we used to do is now baked into web delivered solutions (BaseCamp et al).

This will trigger us to break up a the skills triangle in a different way.

A skills/roles triangle for the new normal

A skills/roles triangle for the new normal

While we’ll still take a slice down the side of the triangle, the buldge will move to the ends of the slice, giving it a skinny waist. The more complex operational environment means that we need to beef up planning (though we don’t want to get all dogmatic about our approach, as existing asset-centric IT planning methodologies won’t work in the new normal). A shift to large numbers of small projects (where the projects are potentially more technically complex) means that we’ll beef up our internal delivery capability, providing team leads with more autonomy. The move to smaller projects also means that we can reduce our administration and governance overhead.

We’ll replace some skills with automated (SaaS) solutions. Tools like BaseCamp will enable us to devolve responsibility for reporting and management to the team at the coalface. It will also reduce the need to develop and maintain infrastructure. Cloud technology is a good example of this, as it takes a lot of the tacit knowledge required to manage a fleet of servers and bakes it into software, placing it in the hands of the developers. Rumor has it that that a cloud admin can support 10,000 servers to a more traditional admin’s 500.

And finally, our suppliers act as a layer through the middle, a flex resource for us to call on. They can also provide us with a broader, cross-industry view, of how to best leverage technology.

This thinning out of the middle ranks is part of a trend we’re seeing elsewhere. Web2.0/E2.0/et al are causing organisations to remove knowledge workers — the traditional white collar middle layers of the organisaiton – leaving companies with a strategy/leadership group and task workers.

Update: Andy Mulholland has an interesting build on this post over at the Capgemini CTO blog. I particularly like the Holm service launched by Ford and Microsoft, a service that it’s hard to imagine a traditional IT department fielding.

Tags: , , , , , , , , , ,

From doctrine to dogma: when did a good idea become the only idea

2009/08/17 in Business-Technology by peg | View Comments

When does a good method become the only method? The one true approach to solving a problem; the approach which will bind them all. The last few decades has seen radical change in our social and business environments, while the practice of business seems to have changed relatively little since the birth of the corporation. The problem of running a business, the problem we work every day to solve, has changed so much that the best practice of yesterday has become an albatross. The methods and practices that have brought us to the current level of performance are also one of the larger impediments to achieving the next level. When did the yesterday’s doctrine become today’s dogma? And what can we do about it?

Our methodologies and practices have been carefully designed to help steer our leviathan ships of industry, tuning their performance to with five and three year plans. The newspapers of today, for example, hold a marked resemblance to the news papers of 100 years ago, structured as large content factories churning out the stories with some ads slapped in the page next to them.

The best practices evident in companies today represent the culmination of generations of effort in building, running and improving our businesses. The doctrine embodied in each industry in a huge, a immensely valuable body of knowledge, tuned to solving the problem of business as we know it.

doctrine |ˈdäktrin|
noun
a belief or set of beliefs held and taught by a church, political party, or other group : the doctrine of predestination.
• a stated principle of government policy, mainly in foreign or military affairs: the Monroe Doctrine.
ORIGIN late Middle English : from Old French, from Latin doctrina ‘teaching, learning,’ from doctor ‘teacher,’ from docere ‘teach.’

OS X Dictionary, © Apple 2007

However, a number of fundamental changes have taken hold in recent years. The pace of business has increased markedly; what used to take years now takes months, or even weeks. The role of technology in business has changed as applications have become ubiquitous and commoditized. The assumptions which existing doctrine were developed under no longer hold.

Today, most (if not all) newspapers are watching their as revenue is eroded by the likes of Craigslist, who have used modern web technology to come up with a new take on the decades (if not centuries) old classified ad.

Let’s look at Craiglist. I’ve heard people estimate that they are doing close to $100mm in annual revenues at this point. Many say, “they could be doing so much more”. But the Craigslist profit equation is interesting. They apparently have less than 30 employees. That’s about $4mm/year in employee costs. Let’s assume that they spend another $6mm per year on hosting and bandwidth costs and other costs. So it’s very possible that Craigslist’s annual costs are around $10mm/year. Their value equation then is 10 x (100-10) = $900mm. That’s almost a billion dollars in value for a company with only 30 employees.

Fred Wilson, A VC

Craigslist has taken a fresh look at what it means to be in the business of classified ads, and used technology in a new way to help create business value, rather than restrict it to controlling costs and delivering process effencies; an approach Forrester have labeled Business-Technology.

The challenge is to acknowledge that the rules of business have changed, and modify our best practices to suit the new business environment because, as Albert Einstein pointed out “insanity is doing the same thing over and over again and expecting different results.” If we can’t change our best practices to suit, then our valuable doctrine has become worthless dogma.

dogma |ˈdôgmə|
noun
a principle or set of principles laid down by an authority as incontrovertibly true: the Christian dogma of the Trinity | the rejection of political dogma.
ORIGIN mid 16th cent.: via late Latin from Greek dogma ‘opinion,’ from dokein ‘seem good, think.’

OS X Dictionary, © Apple 2007

Enterprise architecture (EA) is prime example. As a doctrine, enterprise architecture has a proud history all the way back to John Zachman’s work in the 70s and the architecture framework which carries his name. EA has leveraged large, multi-year transformation programs to deliver huge operational effencies into the business. These programs have delivered a level of business performance unimaginable just a generation ago.

The pace of business has accelerated so much in recent years that the multiyear engagement model these transformations imply is no longer appropriate. What use is a five or three year plan in a world that changes every quarter? Transformation projects have been struggling recently. Some recent transformations edge across the line, at which point everyone moves onto the next project exhausted, and the promised benefits are neither identified or realized. Some transformations are simply declared a success after an appropriate effort has been applied, allowing the team to move on. A few explode, often quite publicly.

This approach made sense a decade or more ago, where IT was focused on delivering the next big IT asset into the enterprise. It’s application strategy, rather than technology strategy. However, the business and technology environment has changed radically recently since the emergence of the Internet as a public utility. The IT departments we’ve created as application factories have become an albatross for the business; making us incapable of engaging anything but a multiyear project worth tens of millions of dollars. They actively prevent the business from leveraging in innovative solutions or business opportunities. Even when there is a compelling reason to do so.

Simply put, the value created by enterprise architecture has moved, and the doctrine, or at least our approach to applying it, hasn’t kept up. For example, a common practice when establishing a new EA team seems to involve hiring architects to fill each role defined TOGAF’s IT Architecture Role and Skill Definitions to provide us with complete skills coverage. Driving this is a desire to align ourselves with best practice, and ensure we do the job properly.

Some of TOGAFs IT Architecture Role and Skill Definitions

Some of TOGAF's IT Architecture Role and Skill Definitions

Most companies don’t need, nor can they can afford, a complete toolbox of enterprise architecture skills inside the business. A strict approach to the the doctrine will result in a larger EA team than the company can sustain. A smarter approach is to balance the demands and available resources of the company against the skill requirements and possible outcomes. We can tune our approach by aligning it with new techniques, tools and capabilities, or integrating elements from other doctrines—agile or business planning techniques, for example—to create a broader pallet of tools to solve our problem with. This might involve new engagement models. We can buy some skills while renting others. Some skills might be sustainable at a lower levels. It is also possible multi-skill, playing the role of both enterprise and solution architect. Similarly, leveraging software as a service (SaaS) solutions can also force changes in our engagement model, as a methodology suitable for scoping a three year and $50 million investment in on-premises CRM might not be appropriate for a SaaS solution which only requires 10% of the effort and investment as the on-premises solution.

Treating doctrine as prescriptive converts it into dogma. As John Boyd pointed out, we should assume that all doctrine is not right—that it’s incomplete or incorrect to some extent. You need to challenge all assumptions and look outside your own doctrine for new ideas.

Our own, personal resistance to change is the strongest thing holding us back. It seems that we learn something in our early to mid twenties, and then spend the rest of our career happily doing the same thing over and over again. We define ourselves in terms of what we did yesterday. If we create an environment where we define ourselves in terms of how we will help the organization evolve, rather than in terms of the assets we manage or doctrine we apply, then we can convert change from an enemy into an opportunity.

There is light at the end of the tunnel. For all the talk of the end of newspapers, some journalists are banding together to create new business models which can hold their own in a post-Craigslist world. Some old school journalists have taken a fresh look at what it means to be a newspaper. Young but growing strong and profitable, Politico’s news room is 100 strong and they have more people in the white house bureau than any other brand.

As TechCrunch pointed out:

Journalists still matter. A lot. Especially the good ones.

The challenge is to focus on what really matters, get close to your customers and find what really drives your business, question all the common sense (which is neither common or sensible in many cases) in your industry’s doctrine, look into the doctrine of other industries to see what they are doing that you can use, and use technology to create a business which their more traditional competitors will find it impossible to compete against.

Tags: , , , , , , , , , , , , , , , , , , , , , , , ,