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!

I thought I should start this category with a brief background so you can choose to accept or disregard my views on the subject of career and work.

I exited undergraduate studies (a completely different blog topic) in physics and mathematics in Australia (my country of birth) and got a job working in a University IT department. Got to admit, I enjoyed the campus life so much, it was a dream job. As an apprenticeship it was exception. Started doing the normal stuff, helpdesk, desktop and network support and progressed up through workstations (DEC Microvax, DECstation) to the bigger stuff (Vax Clusters, IBM Mainframe, SGI Supercomputer). I did the normal stuff, support, system administration, and a little systems programming. Eventually and the need to fund my life got stronger, I moved into management positions and further from my technical roots.

I moved on from Universities to a range of management and consulting positions in various industries (telco, utilities, finance and public sector). A combination of technology deployment, IT operations, architecture & planning with some true consulting (BCP/DR, Risk Management, Outsourcing, Down-sizing).

The one thing I know about myself and can directly see my reflection in my father is the periodic need to throw myself in the deep end. Perhaps a micro-midlife crisis (or perhaps a mid-decade crisis). Anyway, career wise, this came in the form of Sun Microsystems. A friend who I had worked with as an Apple reseller had taken up a job and referred me to a position in the company. It was a career xroads, the world of Sun and the IT Management career I was moving along do not really co-exist. So I took the same decision that has served me well for the past twenty years, I went with my gut and did not analyse the situation too much.

Working at Sun in Australia was a completely different world. I thoroughly recommend people work for the vendor side of the IT Industry at some point in their career. The financial imperative of a company that sells products and sevrices gives you great clarity of focus. Anyway, I was doing similar things in the areas if technology implementations, project management but very little IT management level consulting. After a couple or three years, the micro-mid life crisis struck again. Working in a country of 24 million on a city of just over a 1 million, I begain to realise what a small world we live in.. A fortuitously an email happened across my desk "Project Manager needed for Japan!!"

Once again, off into the deep-end. What do I know about Japan! Except for Japanese Tourists on the Gold Coast of Australia, not much. Did I speak the language (not at all)? Before you know it, that hat is in the ring and the response came back very quickly. "We need you to be in Japan in two weeks time for two weeks and then possibly two or three trips in the next month" Bags were packed and off I went.. A two week gig, became two months and three and half years later, I leave Japan (that is a story for another time). The job was basically DC Management and Support consulting for the largest consumer of IT in Japan. There was also a short gig as a services architecture for a large global customer.

After three years, many days snowboard, getting married and essentially absorbing as much Japanese and japanese culture as a could, I faced my next micro-mid life crisis. I had come to a xroads where I needed to commit at least another 5 years to Japan, or move on to the next thing. Low and behold, an opportunity to do a job in Singapore came across the table. Bags and new family packed, off we go to Singapore.

The work in Singapore involved alot of travel. As a Solution Architecture for Managed Services I supported Sun customers across Asia Pacific. Most notably I spent alot of time in India, China, Thailand and back to Japan. I never quite managed to make it back to Australia. Anyway, a mind broadening experience this was from a diverisity of markets, economies, customers and culture perspective..

You guessed it, 2.5 years later, and a new baby girl, the crisis returns.. This time an opportunity to move to the US was up for consideration. So in May 2006, we arrive in the US to start a job in Silicon Valley working for the services group.

Its been a fun ride and I have lots of experiences to share, some personal and some career and job related. I will try and catalog them here and my personal blog in the coming weeks, months and years. Of course the journey has just begun ...

Whenever you start to talk with companies about IT Service Delivery improvement or IT Optimization, the conversation inevitably turns to business alignment (if it doesn't then you are in even bigger trouble). This alignment is due to the ongoing challenge of the IT Department to provide the link between the "IT Industry" and the "IT Users". In the middle of this tug-o-war of activity is the IT Department, a mediator between the two, trying to facilitate a steady equilibrium.

In the inserted image, the external pressures of "IT Users" are shown at the top and the "IT Industry" pressures at the bottom. By no means a comprehensive list, but you get the point.

"IT Users" can generally be broken into three groups;

Business users - internal users who own the end product of the company.

Consumers - the end customer of the company product which may be totally It delivered

Society - governments, markets, media, culture and many other external environmental pressures applied to a company and its IT delivery organization.

"IT Industry" is strongly dominated by vendors, but influence definitely comes from professional groups, IT media, investors and and other parties who try and influence the IT industry.

So to deal with this IT Service Delivery executives, management and technical staff have a large range of strategies to consider. Through this category I will explore some of my ideas on what strategies are worth considering and some approaches on how to tackle.