What is the rate of depreciation of software, or in other terms, "when does the value of a piece of code become approximately zero?". The second aspect to this is how much of the license fee for a new version is for code that has reached this $0 value.

Why I think this is important is the issue of what is "free" and what is "for fee"..

Surely the majority of the code is untouched for a number of releases, and therefore should have a approximated value of $0. Should you continue to pay for this code, or should you be paying for enhanced code or new functions/features.

This type of model is trying to define open source development in terms of a cost+ model.

So it seems to me that giving away this commoditized code is a reasonable step.

So what does this mean for open source business models;

If you believe all software should be free (as in speech), then this logic will never work. But then again nothing will that involves money.

This supports the "for fee" basis of new and innovative components.

It would not make sense for a completely new innovation to opensource from the beginning, unless you cost of development of the core project would be less than the marketing required to get adoption.

Supports individual developers and other associated parties getting paid for developing features (ie. everybody deserves to get paid for their work).

Does not limit "for fee" to deployment & growth aspects as mentioned in Simon Phipps blog, but all new features and functions.

Supports the move to a single or small number (because competition is good to keep the core code improving) of core pieces of code for a given function (eg. how many OS kernels, RDBMS cores etc.. do you need)

Puts more focus on the open source community as consumers of core code and not contributors (which seems to be a common concensus, because contributors are a small percentage and often vendor funded)

There is no doubt that the core code should also be improved over time, but this can be funded through support and other annuity means. If a community is unable to keep it refreshed, then the typical threat of forking always exists.

$0.02

B

Inspired by some colleagues, I have started thinking about how to get my ideas and thoughts into a more interesting format than the traditional text and pictures. The goal is looking for a higher volume audience than the traditional presentation with the advantages of asynchronous communication.

So I have started rethinking some of my more repeated presentations. I have started by breaking them up into a series of 5-15 minute "slide casts".

I have created three so far and these are the lessons learned;

1. Collecting the tools required to deliver a reasonable quality result
2. No matter how accomplished a presenter, its hard to get the visuals and the audio track "just right" to feel comfortable to publish (probably more so if you are a good presenter)

Tools

It took me a while to find some tools. The editing suite was the challenge. What I have for the moment is;

Star Office - generate the slides and export to JPG

Audactity - record and edit the audio track, export as WAV

Ulead Studio - import the JPG's and WAV, sync the graphics to the audio, export to WMV in 640x480 res, 4:3 aspect at 5 fps using the Ulead Best Quality codec

I will catalog more details on this in a future post.

Content

There will be a heap of future posts on this topic. I am sure its a journey similar to normal presentation skills. What I have tried so far is;

General

Its hard to make something over 10 minutes interesting

Effort gets exponentially larger the longer the preso

Images

Create half the slides you think you need for 5-10 minutes and then half again. Save yourself some editing time.

The "Lessig" method of putting a few words on each slide can be visually impactful for a few slides, can get a bit boring after 10, when you cannot see the presenter.

For complex slides, build you slides bit by bit to keep it interesting.

Audio

Content comfort and preparation are directly linked. If you have not presented exactly the same content numerous times, then you need to practice, practice, practice.

Record you practices. Its fine to practice in the car or alone, but the best thing is to hear your recorded voice. Hear your funny quirks or commonly repeated phrases that make the voice track weird

An idea I plan on trying next is to only have 1 slide as the starting point. An image with no words. Then record an audio track explaining it as I would normally. Then I will build a presentation which best communicates my words. Will let you know how it goes..

Look for more from me..

The most frequently neglected phase of sourcing is the preparation of the enterprise's current IT service delivery. “Don't outsource your problems!” is a well known phrase in the IT industry, and one that is increasingly becoming a reality.

There are a number of key activities an organization must complete before considering the development and implementation of sourcing:

Develop a service catalog

Creating a service framework

Baselining

Preparing for change

Develop a Service Catalog

The first step in preparing for sourcing is to define the range of IT services currently being delivered. For many mature organizations this information should already exist in the form of a service catalog. A service catalog defines IT services in terms easily understood by business users. Each service has the following minimum information:

IT service: A summary of the service in the language of the business user.

Business processes supported: The functions of the business that use this IT service. This is normally a many-to-one relationship.

User communities: The different groups who use the service. These are normally segments into those with different management-level decision making influence over IT services. Budget delegation and organizational structure make this different for each organization.

Service Level Agreements (SLA)/Service Level Requirements (SLRs)

Creating a Service Framework

Traditionally, organizations develop, implement and change IT services in a evolutionary process. Although change management may occur at a functional level (e.g. server infrastructure, software development or network management) to ensure service quality, few organizations have reached the level of having a complete service architecture that integrates all aspects of service delivery and service management. Even fewer are able to integrate this architecture with traditional technology architectures and data models. The result is a collection of processes, delivery teams and infrastructure that have dependancies that are not well documented or understood. In such an environment, the impact of changing to a sourced relationship for service delivery may have a severe negative impact on service quality and performance.

With a good understanding of the IT services being provided by the enterprise through the service catalog, the next fundamental step is to create an architecture for service delivery. The service delivery architecture, or service framework, is made from a collection of reusable modular components.

To identify these modular functional components and build a service framework, enterprises must first understand what processes, input/outputs, service levels, infrastructure and delivery teams are involved in delivering each service.

This information can help easily identify the functional components that are required to create the service framework. A hub must have the following attributes:

Clear service definition, such as SLA

Identified points of measurement

Service management and service operations processes

Defined inputs and dependancies, such as OLAs and UCs

Internal independence (i.e. external dependancy clearly documented and measured)

Delivered by single delivery organization

The service management hub is the essential hub for every service framework in the enterprise's service catalog. It defines the SLA, customer relationship and service management processes between the IT department and business users.

Using this modular approach for re-engineering existing IT services, enterprises are able to create a unbroken chain of service delivery that includes ownership, measurement and component SLAs. This will help enterprises identify, diagnose and improve their ability to meet SLAs with business users. The service framework provides maximum flexibility to sourcing delivery of entire service frameworks or functional components according to the strategy that best suits the organizational requirements without compromising service quality.

Baselining

One of the most difficult parts of developing a sourcing strategy is identifying what should be outsourced and what level of service should be expected. A key instrument in understanding these areas is the collection of information on the current situation through the process of baselining, establishing a quantitative measure of the current state of service delivery in four areas, including:

Financial: Understanding the cost of delivery and business value of IT services is critical in identifying the price a service provider needs to meet. This includes an audit of all the assets and the importance of the service to the organization.

Service quality: The availability, capacity and performance of the IT services. Service quality measurements are the basis of future SLAs with the sourcing provider.

Delivery capability: The maturity and performance of individual processes contributing to the service delivery provides an understanding of the amount and areas of improvement that might be expected from the provider.

People: Knowing the skills and knowledge required to deliver the service allows enterprises to develop a skills transfer strategy to the service provider.

The most difficult of these process is financial baselining. The ability to attach cost of delivery to specific services is impeded by the complicated way IT services have evolved. A lack of documentation of resources and processes limits the ability to do a formal service-based costing financial model. As mentioned in the previous section, creating a modular service framework with defined process, input/outputs and service levels is crucial to successful financial baselining. Using the definitions of the services frameworks and functional components, the amount of resources, including technology and people, can be calculated. If it exists, the business continuity plan is also a crucial source of information for assessing the business value of IT services. A business continuity plan should outline the costs of loss of service, including qualitative and quantitative values.

For a mature organization, service quality baselining should be a basic part of IT service management. Organizations should regularly measure and report the critical parameters that contribute to user satisfaction and business value. In addition to this, the input/outputs of the functional components that make up the service framework should also be measured and reported, if only to the internal IT organization. This is essential if the sourcing strategy includes sourcing a functional hub (e.g. network management) but not the entire service framework. These hub measurements will also feed into the Service Improvement Plan (SIP), as improving each hub will help improve the overall framework. In addition, a baselining process should be performed on VOC to understand user satisfaction and requirements.

An assessment of the current service delivery capability is a critical factor in determining the SIP. An audit of service management and delivery processes will identify areas of improvement. These improvements will need to be agreed upon with the provider as part of the sourcing process. An assessment should measure the service management and delivery processes against industry best practices. The Sun IT Management Framework is an example of this, as it combines a number of industry frameworks and proprietary solutions. The assessment should specifically identify areas which require immediate attention prior to, or immediately after, outsourcing occurs.

Finally, but not least important, is a skills assessment and audit. Included in this process is a definition of roles and responsibilities. This allows an organization to clearly define the skills and roles required from the service providers' delivery organization. This baselining process will also contribute to the development of the organizational transformation.

Baselining resolves big issues for both the enterprise and prospective partners. The collection of baseline data allows the enterprise to understand the state of what is being sourced. Accurate information on the current state of delivery reduces risk for both the organization and provider, helping lower risk margins built into pricing and resourcing of a sourcing solution.

Preparing for Change

The implementation of any sourcing strategy, big or small, can have a significant impact on the enterprise. It may threaten employees' views of job stability and lead to the creation of a new organizational culture. This type of change requires a specific focus on change acceptance.

At the heart of any change effort is the people who make commitments to move the change forward. The objective of change acceptance is to have that individual effort mobilized and committed. As outlined in Figure 4 below, all of the other activities touch it, are linked to it, and drive toward it.

From the previous work completed in preparation, enterprises should now have enough information to engage in a complete change acceptance program, which requires the following key features:

Map the transition: Just as a topographical map depicts the lay of the land and provides direction to a destination, change should be charted and planned, providing steps toward the vision.

Engage support and resistance: Actively seeking out resistance and leveraging the support of those behind the change helps enhance the change effort by learning and responding to differing input.

Integrate the change: Driving the change into the DNA of the enterprise to improve staying power, such as replacing old mindsets, systems and structures, and inserting new actions and behaviors.

Focused leadership: Leadership, whether a sponsoring executive or team leaders, provides focus and motivates commitment through visible actions and behaviors around communication, resourcing, and time and attention to the change.

Compelling business need: The change must originate from a business requirement that is either a response to a threat or a movement toward an opportunity and must speak in such a way as to provide motivation to get others on board.

Shared future state: The future is expressed in such a way that it creates a picture of what the change will look like, and people can see what they will be doing differently when the change is fully functioning and in place.

Assess and adjust: Throughout the change there is constant movement, collecting and learning from the input of key stakeholders and adapting the change effort in response to the input.

Note: this post is an extract from the Whitepaper "Smart Sourcing: An implementation roadmap"

The traditional outsourcing method has had its celebrated failures. Regular reports are published about cost overruns, contract disputes, and poor customer satisfaction. Many of these failures have been due to inflexibility of the sourcing contract, which may not easily change to respond to market pressures and business requirements. It is commonly known in the service industry and outsourcing is cyclic, with companies moving from in to out source and back again. This is extremely and distracts the IT organization from core business.

Organizations need to be able to change the financial model, adjust the IT service portfolio and alter the technology landscape. The blame for this is not entirely in the hands of the service provider. While traditional outsourcing places responsibility on the provider, in reality, a sourcing method has demands on both the organization and the provider.

Common causes of failures are:

Lack of direct business drivers: Often existing internal IT departments and business are not integrated. A gap in knowledge exists between IT's capability and the business's requirements. Sourcing providers are brought in to solve this problem but are only able to understand the organization at a snapshot in time.

Failure to properly prepare the IT organization: Sourcing is undertaken to resolve a problem with the current IT service delivery. The provider has the task of reforming the delivery method in an environment that the organization had been unable to do for many years.

Adversarial provider selection and contract negotiation process: The use of outsourcing for cost reduction as the principle method for evaluating a sourcing solution makes a conflicting relationship between organization and provider.

Theoretically derived service levels: A lack of historical knowledge of current services levels and capabilities puts the onus on the provider the commit to services levels that have no baseline reality

Poorly planned transition and implementation: Often the solution design and transition phases are performed by completely separate teams (e.g. organization senior management and provider sales vs. organization technical staff and provider delivery staff). Transition is often less that 20% of the solution design effort, but can make or break the success of the sourcing solution.

Smart Sourcing is an evolution of the outsourcing that mitigates the limitations of the traditional sourcing methodology to provide a win-win relationship for the business and the provider over the long term. There are six core principles that serve to guide the implementation and strategy for the sourcing relationship.

The three principles of implementation are:

Preparation of the enterprise for outsourcing by designing the existing IT service delivery in a flexible, modular way that provides maximum flexibility in sourcing strategy. Enterprises should design a measurement framework into the environment to collect real data about service delivery performance. Proper preparation limits risk for both the enterprise and the provider.

Planning provides a picture of the end state and a plan for achieving the vision. Strategy is practical—not mission and vision statements—and includes a business case development process that uses measurable information about the enterprise to identify areas of business value. Change acceptance within the organization is a crucial part of the planning process.

Partnership is the key to long-term success and building a community of providers who share common goals.

The three principles for strategy development are:

Flexibility helps build relationships through service level agreements (SLAs) and contracts that provide for shorter term relationships that can change scope. Within the term of the relationship, an enterprise may need to change IT services, technical architecture, service management processes, cost structure and staffing profile.

Choice in a multisourcing strategy allows for the selection of the most suitable provider for each task. Multiple providers reduce provider lock-in and give greater choices for future sourcing relationships.

Control lets enterprises carefully select the capabilities needed to retain for business value. As a base, enterprises may want to retain IT service management, architecture/data management and business consulting.

Note: this post is an extract from the Whitepaper "Smart Sourcing: An implementation roadmap"

If you were to consider two adjectives that most define Red-shift it would be easy to select "Growth" and "Innovation". Growth is the fundamental descriptor for the premise of being "under served" by Moore's Law. I would propose Innovation is the primary driver of Growth. The reason for this is the type of Growth needed to be a "Red=shift" workload cannot be created by incremental improvement on existing products/services.

So Innovation is the fire that is powering the Red-shift. So what is stoking the fire!

Lets take and short detour and catalog the key characteristics of the Open Source Software (OSS) movement. We can quickly identify;

low barrier to entry/exit (cost, legal obligation)

transperancy of governance (roadmaps, testing, development process)

unrivaled access to resource (quantity, quality, motivated)

The result is the OSS movement has put an exponential amount of features and functionality in the hands of a wider and more diverse group (eg. globally, industry, background, market) of entrepeneurs. So you can picture the combustible material resulting from the reaction of combining the ideas of this large group of people with the expanded ability to execute through software. Important to note that OSS is not only the tools to execute, it is a reactive agent. People need raw material to create ideas, which is most often a combination of information and personal experience. The OSS community not only feeds from these ideas but is a significant contributor by putting in features that are executed in unique ways.

So the spark of Innovation is created by mixing the features/functions with wealth of ideas. But what is sustaining the fire ?

The answer might exist by looking at the first wave of "Red shifted" demand. The Internet boom provided access to a completely new route to market for service. As described above, the same scenario existed to connect ideas to execution. The two barriers to execution at the time were technical capability and access to physical infrastructure.

It is true the foundation of the Internet was HTML, but to build something functional and architecturally significant, you needed to speak the languages of Java, PHP and SQL etc... So unlike this generation, the "Red Shift" was dampened by the fact that execution required the use of traditional developer tools and knowledge of programing. As a result, the education system created a combustible natural resource of developers and university graduates with a higher level of technical competence and knowledge of the "new economy". A material that has laid dormant during the infamous .COM "bust".

The deployment barrier of infrastructure was also lowered by the first .COM boom. New meanings were created for the words "Start up", "Going public" and the general public started to learn about the business of private and public investment. This wealth of money was driven into an unprecedented investment in the Internet and the infrastructure that supports it. The new-economy drove Moore's Law for many years and resulted in commoditizing access to processing infrastructure. The top line trend was an initial huge browth in processing capability (CPU, storage density, network bandwidth) during the boom, then with the bust, a large reduction in cost.

So courtesy of the first boom, the barrier for execution of processing infrastructure is small.

The final note is the OSS movement is not just delivering end user features/functionality. A natural trend in all forms of technology is to constantly improve usability so to address the broadest segment of the target market. OSS is no different, the trend is reducing the barrier for execution by making the software that allows you to realized the "ideas" easier to use.

So we can conclude, there is loads of combustible material in the form of developers and MBA's with the knowledge and creativity and a wealth of infrastructure capable of carrying innovation through the critical concept and market entry stages (high cost, low revenue). The OSS movement has created the spark to ignite this material with an unequaled frequency and ferocity. So OSS is fueling the fire of Innovation which is powering the engine of Growth that drives the "Red Shift" :)

Footnote: Couldn't it be said that bandwidth, data storage or CPU is "Powering the Red=shift". Its true enough that they all play a role, but it is the application stack that sits on top of the IT Value Chain and most often directly connected to the driving source of innovation, PEOPLE!!

This is a very quick article to highlight some ideas from a presentation I gave in 2005 at the itSMF conference in Singapore. With the release of ITIL v3 and its increased detail and breadth of coverage. More than ever the question has been asked, "How do you implement ITIL?". The most clear answer I got was at the same conference from the then CEO of itSMF, Aiden Lawes. "ITIL Cannot be implemented!" Never a truer word has been said.

ITIL is a collection of IP representing some guidance on the processes, people and technology to support IT Service Management. IT does not provide the instructive level of detail required to implement and that is a good thing. From my last 8 years working with customers around the world. The difference in the issues, drivers and priorities that exist in different economic markets, cultures and industries is significant. To delve into more detail would immediately cause ITIL to divert away from its current relevance.

So whats the alternative. If you company has had to execute any significant organizational change or big IT project (eg. an ERP implementation) then it probably already has a change adoption process.

The image on the left highlights some of the things most organizations keep in the bag of tricks to help with this process.

So my favourite concept that underpins everything I do it "alignment". The industry press is full of quotes and the research organizations are full of data with info on what causes projects to fail. Big with non-quantifiable metrics would be two of the top 10. So I like the concept of the continuous improvement approach to adoption of ITIL. . Success is "all about" aligning your goals and requirements with the "customer" (however you choose to define that term) and unleashing the innovation within your staff. The critical concept of continuous improvement is to attack the problem one chewable chunk at a time. Process by process, service by service, what ever you urgency and goal requires.

Innovation is the key.. The missing piece of the puzzle which is lost for ever by companies that "outsource" this improvement process. There is alot of knowledge and creativity within the your current staff. They need some facilitation to let it out and a process to make there voice heard. Now BEWARE of the first big pot hole. DO NOT adopt continuous improvement methodologies religiously. They were mostly designed for the highly rigid environments of manufacturing. You need to follow the same approach you do with everything. Adopt, experiment and adapt.

One of my favourite methods for continuous improvement is based on SixSigma (I can hears the screams and uproar as I type). The adaption I have worked with which was also part of the GE culture is the use of facilitated workshops to execute smaller improvement projects. Its light, effective and mostly enjoyable. There are quite a few other key principles of Six Sigma that I like;

use internal staff to drive the change (Blackbelts)

measureable and quantifiable goals

lifecycle approach to change

stay externally focussed (not process focussed)

So the long and the short is; "Dont implement, ADOPT and ADAPT"..

I have always been interested in the old addage that "the best solution is not always the most successful". This is always represented by some of the biggest battles for consumer success;

VHS vs Beta

Windows vs MacOS

Mainframe vs Open Systems

Linux vs UNIX

CDMA vs GSM

NeoGeo vs NES

NES vs Playstation

Playstation vs Xbox

Laserdisk vs CD/DVD

DVD+R vs DVD-R

DVD vs. BlueRay

Wordstar vs Word Perfect

Word vs Word Perfect

the list is endless (as is the garage of most people with outdated tech)

In recent times the emergence of Linux, opensource movement and concept of the "participation age" has made me think; Is success defined by people or product? Is ultimate success defined by how you deal with the people or the product? How will OSS develop over the coming years? What are the tipping points?

Now I have done my post-grad business studies and have read enough books to know most of this concept is not unique thought, but its a critical thought process as I apply the learnings to Open Source. The application to OSS may very well be unique.

If you are a believer in the world of economics and the concept that markets shift to achieve efficiency in the absence of regulation etc.. A highly diplomatic person would vehemently argue that you need to deal with both.. Well, its my blog so I get to state my opinion and that is "People" wins over "Product".

Now the cynics would say "Thanks for stating the obvious!!", and there is truth there. But what can we learn from these various use cases. Can we create a catalog of drivers to stick in the model that be used as strategies when trying to enter the market with a new product, or even trying to get a project approved within the enterprise.

So Windows vs. Mac vs. Linux is the classic long running battle for the desktop which has existed for at least the last 20 years. I doubt that there are many people that would debate too strong that the technology design and execution of the Mac is superior to Windows or Linux across the complete range of consumer user requirements (Windows and Linux do have unique areas of strength). People would also recognize that Apple addresses the needs of the people in both the product and the marketing/advertising/sales etc.. So why does windows continue to dominate ?

Some ideas;
1. Market entry - whether first or second, the dominant player enters the market at a good time and establishes rapid growth. Apple was blazing the path to the individual whereas MS rode the wave to the business.
2. Killer apps - the product/company addresses a specific function or need that was lacking in the incumbent or completely absent in the market. Apple really focussed on the individual, but the market was for the business $$. MS hit the people aspect at a business level.
3. Business model - a good business model can protect a company from having the "best" product or addressing all the people's needs.

So what about the long run ?

There is a natural tension however between the forces that protect a product that does not meet the needs of the people. Eventually balance will be restored. Either MS moves the product into a position to relieve this tension or the competitors will ride the wave of discontent and pounce.

$0.02

So ITIL V3 has finally been launched;. After a number of years constination and debate over what direction it should take, they finally reached agreement or gave up trying to get it and just moved forward. The big changes that are obvious at first glance are;

1) More focus on business integration

2) A lifecycle approach;(meaning continuous improvement amongst other things, but unfortunately to ITIL the focus is on inception)

On the surface, these are good changes. In fact I have been working in my current role for at least 5 years and have always promoted as the ideal way to adopt service management. Time will tell once we read a digest the books and try and apply the added concepts, whether the execution is good.

The big down side is they changed the structure of the documentation, which from what I can tell means V3 is now a complete upgrade to V2 and very little of the existing material is portable. So the industry that has built itself up around the brand of ITIL has a huge amount of potential revenue in training, individual certification and consulting. Its not a incremental addition, its a complete upgrade (cold install perhaps). There is some talk of how to bridge to the V3 certification (in place install if you may); but nothing is confirmed.

As I read the launch material and browse through the book summaries, I wonder if the concept of a service management "best practice" framework is a good open source project. It seems the current books have one or two authors each, whose experience might be somewhat limited in geographical, industry and market exposure. I understand through the itSMF there is a community of knowledge behind these authors, but the formalized structure and the structured release cycle will always limit this level of consultation.

I have always found that every minute I spend not working in this area the process of losing connection with the needs of companies begins. This formalized structure requires professional content contributors who are unable to spend this time in front of the customer. The area of service management is a continually maturing set of process and the development cycle of a centralized organization is perhaps not going to meet the needs of the community. In reality this is essentially the reason why all open source or "participation" events occur. The voice of the majority finds a way to express itself when there is a real or percieved disconnection from between the masters and the population (participation event, opensource, revolution, social unrest are all the same :)

A key role of a configuration management database (CMDB) is to store and report information about configuration items. A configuration item can be something as macro or micro as you like. It can be "the street address of your datacenter" or "the dip switch setting on a NIC". It stores all sorts of useful information on each item, like versions, known errors, history of incidents/upgrades, you name it and that information "could" be stored in a CMDB.

The Kevin Bacon game is an old favorite based on concepts of the shrinking world mostly attributed to the author Frigyes Karinthy. The game version is simple: pick any 2 people (actor, director, grip, stuntman) in Hollywood (or the world depending on the version) and there are no more that six links required to relate those people together based on there link to Kevin Bacon.

The underlying concept of the Kevin Bacon game is the utopian vision of the Configuration Management DataBase (CMDB).

A CMDB stores relationship information between each configuration item and other important bits of information (e.g. incidents, service levels, etc..). The way in which this information could be used to improve IT services delivery are limitless. Software Licensing metering, patch analysis, maintenance impact analysis, TCO calculations, capacity management, root cause analysis, incident management to name just a few.

One word of caution. The only thing more mind boggling than the limitless uses of this information, is the technical challenge of making it happen (Demystifying The CMDB, Andrew Conry-Murray). A detailed CMDB would need to store a relationship diagram that would quickly look like a three dimensional bowl of spaghetti. The ability to manage this data in an automated fashion (hence the need for a tool) becomes critical. You must recognize that collecting and managing this information needs a range of processes, including discovery, reconciliation, federation, synchronization, access control, auditing and reporting.

"ITIL cannot be implemented"

I was sitting at a conference in Asia a couple of years ago and a senior member of itSMF got up and made this statement. I can here the ITIL community screaming from here :), but it really resonated with me. Don't get me wrong, I am an ITIL supporter, ITIL Management Certified and active supporter. I had been presenting a continuous improvement approach to ITIL adoption in the conference, so the concept was completely aligned.

My simplistic view of ITIL is it is a collection of good ideas connected together as best practice reference framework. You would be hard pressed to find someone who has executed all of the processes in the framework, and even difficult to find someone who has completely implemented one. A true single CMDB does not exist (you can look here for some products that claim to do some of it), how could anyone have implemented it? Anyway, the rule of ITIL adoption is to work out what benefit (business, operational, etc..) you want to get and then adopt the parts of ITIL that help make that happen.

The classic case study for the failure to have this focus on benefit is best described by efforts of the 2007 F1 GP Factory team. Over the winter break, they went away to develop the FY07 car. The project goal was to improve every aspect of the previous years car. The best practice framework for air flow, engine power mapping, suspension are pretty well known, and these guys strived for the very best execution they could achieve. When they got to the track, they had spent $3 million USD on a car that was 1.5 seconds slower than the previous years car. As a race commentator said; "They spent greater than 3 million dollars on something they could have achieved with a 10 buck lump of lead".

Lesson learned: Always focus on the desired result !!!

The the critical point of adopting Configuration Management is identifying the right detail of information (configuration items) that will achieve the value you are trying to achieve. Don't start trying to catalog every line of a configuration file or field in a database, if your goals are achieved by basic asset management.

From Wiktionary:

thunk (plural thunks)

1. (computing, functional programming) a delayed computation
2. (computing) In the Scheme programming language, a function or procedure taking no arguments.
3. (computing) a mapping of machine data from one system-specific form to another, usually for compatibility reasons, such as from 16-bit addresses to 32-bit to allow a 16-bit program to run on a 32-bit operating system

I think my Blog is most represented by definition (3). The goal being to take machine data from my head -> blog, but definition (2) is relevant, because I am taking no argument (editing) and by definition (1) as I get older, the computations are getting more and more delayed :)

In my previous post in "Delivering IT Services" I discussed the pressures that impact the average IT Department in the way the delivery IT Services. These pressures come from the Users and the industry. Success is defined by how the It department gets alignment between these two opposing forces.

I would propose an essential tool for doing this is understanding the "IT Value Chain". The "Value Chain" provides a simple framework for translating the "Users" needs in the form of "Business Objectives" to the "Impacts on IT" which is the definition of requirements from IT to meet these objectives. The value change continues to develop more detail by defining the "IT Initiatives" required to deliver to these requirements.

The next important step is to measure these initiatives against a IT Departments capability to deliver these initiatives. This analysis allows you to understand strengths, weakness in developing an implementation plan.

So, the response to this concept is; "Duh, its obvious!!!" Well my only response is I very rarely see organizations practicing this discipline. It is common sense, but it is not easy. Under the pressures of day-to-day service delivery, this practice is a difficult thing to maintain. It can be considered a management overhead to delivering result. The whole area of ITSM and ITIL is designing around building process and practices that operationalize this practice.

Another reason for this not happening is inability of an organization to clearly state its business objectives. Particularly this gap occurs between executive management and middle management. Business objectives often has many layers, goals, strategy and tactics, often there is not linkage between these layers of objectives. As IT Professionals, this is a problem we cannot necessarily solve. We contribute to the solution, but it requires all the management to have discipline to create this linkage. I have seen people succeed in building this linkage through IT projects that build this linkage (eg. ITIL adoption or Business Continuity), and I have seen a similar number fail dismally.

So whats the "net-net"? Its really about "Do you know how what you are doing contributes to the business objectives to the company ?"

I started blogging this week and have been trying to get some things out of my brain, to make room for some more useful stuff.. I expect I will get some posts done in this future which are more substantially researched content which might serve valuable. But for the moment, you have to indulge my ramblings..

Today I wanted to get the concept of "Darwinian Architecture" out there.. So what is Darwinian Architecture ?

In simple term, current architectural principles focus around plans, blueprints and patterns.. This view provided a great reference framework for people to try and apply. It allowed for the adoption of a discipline which was crucial to the next phase of deployment (ie. engineering)!!

Rapidly the industry has now realised that in a highly marketing driven and growing economy, technology adoption is far more dynamic. Additionally, the IT industry has a love/hate relationship with standards, defacto standards and innovation/kaos.

So Darwinian Architecture is the concept of enterprise architecture is a process of evolution. In evolutionary terms (my simple intepretation), nature spontaneously generates a change in a species (innovation). This change is accepted or rejected (Natural Selection) depending on the success of animal (product) within its environment(market/economy).

The alternative (and to a certain extent more manageable) is the paradigm of urban planning. The difference between urban planning and evolution is the former assumes some degree design criteria of target architecture/plan/blueprint. Even though this is a fairly loose concept in urban planning because of the complexity of the architecture. Evolution assume no future state (I ignore concepts of faith and religion), but there are some basic contraints defined by the environment, and the sciences of physics (gravity, etc..).

So my plan in the near future is to put some more substantial thought to the impact of this concept on IT Architecture & Engineering. Lets see if the paradigm sticks and if some concept of framework or methodology comes out to help manage this process (eg. managing evolution sounds like a great concept :)

As I have only been blogging for a few days, most of these initial entries are just stuff lobbing around in my head. Not well researched, insightful or worthy of traditional publication. I suppose that one of the advantages of blogging. It allows you to get stuff out of your head quickly.

I have always been an avid observer of the IT industry. My career started during the mid-cycle of the IT boom in Silicon Valley. I watched from the outside companies like Sun, Oracle, Apple changing the IT landscape and felt the impact as the technologies and services I supported changed beneath me.

One moment in my career that gave me a perspective of vendors, was attendance at an Apple Developers conference in the San Jose convention center in the 90's. It was near the Scully transition, but the clash of professional management and the traditional Apple culture was still evident. I also got to spend some time in Silicon Valley for the first time and experienced some of its energy.

Another moment was my involvement with DEC early in my career as part of the University IT services organization. At that time, the culture and energy that made that company great during the time of its founders was almost gone.

So my mind always wondered, "What happened to DEC and Apple?"

A reasonable question and I think the answer lies in the founding fathers of the various companies. The energy and culture of a company is definitely defined by its founders. Their on-going leadership is what gives the company a personality, its connection between a paper-based definition of the company (papers of incorporation, annual reports) and something real and tangible. Its true that companies succeed without involvement from the founders. Some truely great CEO's have made their mark (eg. Lou Gerstner, Jack Welch, Carlos Ghosn), but these are rare cases. From what I have read in the various biographies, they were great leaders who redefined the culture of the company. They founded a rebirth of a new company culture along with managing the business.

DEC and Apple (Compaq maybe also, but I don't know the history) give the great examples of companies who failed to deliver as the mantle was passed to professional management. Apple even proved the point even further as it reclaimed its culture and success through the return of a founding father.

So why to I like working for Sun ? A big part of it is the continued involvement of a few of the founding fathers, and some guys who are the founding fathers of significant IT industry icons. Because of this, the culture of Sun is strong, even during the trouble past and moving towards the optimistic future.

Why does Sun attract smart people (no reflection on the author of this blog) ? Because smart people don't just come to work to make money. Smart people want to be apart of a community that is trying to do something. They want to work in a company culture that strives for innovation and participation. There are few companies that existed during the first IT boom and that are in the same business that have retained that cultural tie to the founding father.

So the evolution to the next step in a vendors life is inevitable. Time marches on, and nobody lives forever. I think transition to the next phase needs to be handled much like parents to children. The values and culture needs to be carefully imprinted on the next generation over a long period of time. The child needs to experience the parents values and then at some point the child seeks independence. A vendor/company is not a business that requires hiring a professional manager and a fixed transition, its a living breathing community.

Its important to be up front when you a essentially giving your opinion. I have no desire to rule the world or become incredibly wealthy. My goals are to make the most of my life and enjoy the journey.

Nothing I say here should be interpretted as condoning a "live to work" attitude. I am definitely in the "work to live" side of the equation. But work takes alot of time and you need to live that part of you life, so make it rewarding..

In that context, I offer my opinion of "10 concepts to help live your career";

1. Work with people you find interesting/challenging.
2 Always be professional and courteous to all (its a karma thing and applies to all aspects of life)
3. Seek a mentor(s) who has had a career you find interesting. They are the biggest source of opportunity.
4. Try to work in the same physical location as your direct management.
5. Take the opportunities your gut tells you to do. Don't listen to your mind.
6. Don't overplan the next career step, you may miss an elevator.
7. Be aware of company politics, but don't make it a profession.
8. Contributing to your community (social, professional, industry) is not your job, but is good for the career and soul.
9. Don't dwell on the setbacks as every negative will eventually deliver a postive (karma, ying&yang, goes around comes around, ..cloud has a silver lining).
10. Understand that there is "what you know about yourself", "what others know about you". Self awareness is the most powerful capability.

How do you know if you are an consultant, an engineer or an architect. Are you really a manager like your title says ? Is your title ambiguous and you are doomed to travel your professional life with no identity or sense of community.

I have since the begining of my career struggled with my identity. Initially it was easy, I knew no better and happily accepted my as "system administrator" or "systems programmer". I still had little or no chance of providing a simple explanation to my family what I did. answer: "Oh Brad, he works in computers!" response "Ahhhh!"

Then I as I started dealing with outside organizations, the business card became a currency of work. My job title and my business card title increasingly moved apart. My job title became a fixed descriptor within a HR system to define a pay grade, and my business card title became a ceremonial exchange of seniority and importance.

Recently titles have been used to determine membership to a community. Am I an engineer, architect, manager or consultant. None of these have a clear definition, so I could call myself a "Consulting architectural engineering manager", but the printers would have a headache with the business card, so again I choose. If I choose "architect" then I am no longer considered suitably technical to be part of the engineering community, if I choose "engineer" automatically the communities believe I have lost all knowledge of customer requirements and business objectives. If I choose consultant, then both the former communities recognise me as a generator of paper for the sole purpose of keep bookselve companies in business. To be a manager, traditionally describes leasdership and importance, but to most it brings the destain of a bureaucrat.

So mostly I pick titles that cannot possibly be attributed with any meaning. "Program Manager", "Engagement Manager" because the automatic response is to ask me what that means. This gives me the opportunity to describe more about what I actually do, in context of the person I am talking about.. Unfortunately that strategy has its limitations. I now belong to know recognizable community, a outcast amoungst my peers :)

So now I ponder am I a architect or engineer. I think the answer is the former, and I will try to explain why.

In simple terms, an engineer to me is a person who takes a set of requirements specification and turns them into some tangible product, or a person who takes a creative idea (requirements without a customer) and turns them into a product/technology. In a "2.0" world, taking multiple products are putting them together to create another new product is valid engineering. To work with a truely gifted engineer is a great experience, and one I have experienced a few times.

An architect however takes a users vision of there requirements and turns them into a tangible customer requirements specifications for engineers to execute. Additionally, architects can take products and work out frameworks (architectures) of how to put them together to meet various visions (for theoretical customers).

Its the same paradigm as the building industry. Within the building industry the same sliding scale of people exist within those two roles. There are architects whose plans are very engineering in nature and there are engineers who works is very architecturally valid. So there is always a blurring between these roles.

I think within that continuum you must be capable of existing at one end of the spectrum (technology execution vs. customer vision) to consider yourself in that role. So I think my alignment is more with customers than technology, which makes architect the more suitable choice.

Its obvious as the career journey continues, I will still call myself whatever happens to be the move effective title and label to accomodate the ceremony of business, but I am what I am!