Enterprise Technology & Strategy Games

“There is absolutely no way that my infantry can withstand being battered by afar with artillery and then overrun with heavy cavalry. I should have invested more in research of military units rather than building a church, maybe then I would have a chance of survival.”

That is usually what goes my head when the computer is about to trounce me in Age of Empires III. While it would be easy to dismiss my failure as poor resource management generally, it would be more accurate to say that I failed to invest resources in small projects like turning out cavalry and guns and instead fed it into a larger project like building a church.

By the time the enemy arrived I barely had any defences and the church wasn’t complete and couldn’t deliver on its promise.

Company at War

It might seem like a stretch, but I believe the development of enterprise technology infrastructure is a lot like playing a strategy game. You have a finite set of resources and you need to structure your acquisition of technology so that it delivers the most benefit so that you can cope with the oncoming assault.

Whilst it is not likely that your corporate head office is going to be besieged by artillery (unless you really pissed off your customers), there are other challenges that you will need to overcome.

At Readify one of the challenges that we need to deal with is growth. We don’t want to stop growth, but there are some side effects of growth that are not necessarily desirable. For example as the ranks of the billable services organisation grows there tends to be a corresponding growth in the number of support staff required. How do we maximise the impact of those support staff?

Humble Beginnings

A little while ago Readify went through its first round of growing pains where managing the timesheet reconciliation and invoicing process became too much for one person (the CEO) to handle. At this point in time we hired some support staff to execute the process - but this effectively just moved the problem. Eventually we recognised an opportunity to tackle this problem with technology and we built our own timesheeting system on top of CRM which allowed us to pre-fill timesheets and turn the process for the services organisation into a simple tick and flick. This reduced the time it took to get timesheets into the system and usually resulted in more accurate data.

We learned a lot about the value of small systems development in that one exercise and since then have been making incremental improvements to the system - if we tried to build the system as it exists today from scratch we would probably fail because we wouldn’t have been driven by real requirements and would have been distracted by allure of building a church.

Fast forward to present day and our internal development team has released a system which works in a fashion similar to our timesheeting system which allows us to capture knowledge and distribute it throughout the organisation. For a long time we have wanted a “knowledge framework”, but to be honest I don’t think we could have come up with the solution we did unless we learnt the lessons from building the timesheet system.

The Technology Map Emerges

Where this starts to look like a strategy game is that in addition to actually getting a functional system at the end of a development cycle, we get a set of new technologies that we can then combine to build a new system. The following diagram is a hypothetical technology map for Readify including some existing and future systems, and technologies.

Just taking a moment to explain the current state of play. Both the Timesheeting and Knowledge Framework systems exist today and are systems we wanted. Other systems presented in green are also systems that we will probably want as we grow as a company.

The Tag Relationship Mapper is also a system, but is presented in blue to symbolise the fact that its not necessarily a system that we could justify building in its own right except that it enables a number of technologies (Crowd Voting/Structured Tag Cloud) which could lead to us building a better skills matrix and improve the search of our Knowledge Framework by adding scoping to the already expanding tag cloud - and ultimately some of these technologies could lead to computer assisted resource management which is essential if the company doubles its size.

Investment in Internal Systems

Sometimes investment in internal systems is an obvious thing to do, other times its less obvious and you have to look not just at the function of the system but the scenarios in the future that it will enable, but in order to get to that stage you need think ahead and understand what your technology map so that when the challenges actually arrive, you are ready and have time to respond.

Consulting Anxiety

Occasionally when I am working out in the field flicking between short term engagements I can develop a bit of Consulting Anxiety. Technical folk are often introverts, and before I came to consulting I would have definitely put myself in that category.

Things that helped me overcome it were forming, and regularly presenting at a user group, presenting at larger technical conferences like Tech.Ed and generally getting out and socialising more. However - every now and then I can see myself reverting back.

For example, from the end of November I had a good block of off-site development work and a good chunk of annual leave. When I got back from leave I went into a consulting engagement feeling a little bit uncertain, then, once again when I had a different client that week - and this week I had the same sensation.

On one hand it is refreshing because that added stress possibly gives me a bit of an edge, but on the other it can be quite debilitating as you debate with yourself the merit of keeping doing this kind of front-line technical work (if severe cases).

I once attended a consulting workshop by Graeme Simsion and he described the “accidental consultant” phenomenon. The gist of it is that consulting is something that _happens to you_. In my case I seemed to do a reasonable job at developing software, reasonable enough for others to start asking me my opinion about the software that they are developing - and hey presto I am a consultant.

When I find myself a bit anxious about a consulting engagement I usually talk myself off the ledge by reminding myself that I have around eight years experience with .NET (yep, I started using in 2000) and that I could probably just let go and let the benefit of that experience flow a bit.

No need to be anxious.