Saturday, September 8, 2007

Whereto, CTO?

In Sydney, I have had the opportunity to catch up with a couple of former Insession colleagues. It’s been a year now since I left Insession / ACI and went over to GoldenGate, but I still enjoy a discussion with the lads.

Peter Shell, who used to manage the Sydney development team has now moved on to a new job as the boss of IT across AsiaPac. This is bringing him face to face with many of the issues many IT exec face today – dealing with an ever-demanding user community while navigating the vagaries of regulation and compliance. I often loose site of the fact that ISV development shops share many of the same issues as the corporate world and where any outage at all can put a project at risk as valuable time is lost.

Peter is known to many of us as the former leader of OzTUG and spent many years associated with the event I always looked forward to – in a few weeks time there will be another OzTUG event that will take on a different look as at aligns with other HP activities within the region. It will be interesting to see how the now format fairs.

I also met with Neil Coleman, the chief architect of Insession responsible for bringing the ICE product to market. Neil was very instrumental in the development of the follow-on products WebGate and SafeTGate – now very much integrated into ACI’s payments products. Neil is now developing a technology group and mentoring others to take on more responsibility.

Neil was particularly enthusiastic to relay to me how the original ICE product – a NonStop implementation of core IBM communications protocols and services – is now being groomed as key infrastructure components in support of ACI’s cross platform initiative. Already, key communications modules are running on a number of Unix platforms including HP-UX and shortly, on IBM’s zSeries mainframes. The irony here doesn’t escape me at all – as Star War’s Darth Vader would say, “ the circle is now complete; the student is now the master!” Neil and his crew have taken a sliver of IBM’s mainframe SNA code that they first developed for NonStop, then added support for HTTP, XML, and SOAP, thrown in a healthy amount of security, and now have it implemented back on the IBM mainframe superseding any need to run IBM middleware – even for comms!

In talking to Neil I was reminded that the role of CTO was evolving: just recently, I was asked by a leading IT manager who really does understand that he needs a technical leader and a group responsible for architecture, “how does one motivate such a team, and how do you convince your CEO”? Surely, he went on to add, “do you know where such a document exists or maybe you yourself have something like this”?

At first, I had to believe there was a wealth of material out there in Gartner white papers and in popular magazines like CIO Magazine. But seriously, do any of us have the time to wade through these publications – and shouldn’t we just know all of this instinctively?

As I began to look into this in a bit more detail, I began to recognize that the right answer is - maybe! It depends! It varies across different groups! All pretty wimpy answers on the surface – so I went back to basics and looked at what I have been involved in over the years.

Just before leaving Insession and joining GoldenGate, I spent about a year at ACI’s HQ in Omaha working in the CTO office with a minor role looking at open source usage across the organization. Within ACI there was an architecture group as well as a Technology Steering Group. The Steering Group included some stellar technicians. But what I came away with is that, even in large organizations, it’s not easy to have an architecture group too far removed from the daily development activity. Documenting recommendations and defining models and templates is all well and good, but in some situations the technology moves so quickly that there’s always the risk that for all the good work that is put into an architecture option, the industry has moved on and there’s just a better way to do things.

The Steering Group was expected to “keep the hand on a pulse”, but the distinction between its role and that of the CTO architecture group was blurry.

Within GoldenGate we do not have a CTO per se – but rather a VP of Technology who stays very closely connected to prototype any new “areas of interest” deployment. In other words, as we push into a new area or try a new technology, as we find a customer or partner interested in trying it – then his team become intimately involved. Supporting the VP of Technology is a group of specialist architects experienced with different platforms and operating systems. To date, I have seen this model working well.

But back to the question – do we need a CTO today? Do we need to have an architecture team? From the above experiences I have had across a number of ISVs – the answer is yes, but with a caveat. Don’t put too much distance between such a group and the folks charged with getting their hands on the code. As you descend into smaller ISVs, the role is not necessarily a full time job – often the founder performs this function.

Within the user world, someone has to take responsibility for setting directions, for putting together roadmaps. There is a definite need to have someone staying just one step ahead of the offerings from key vendors and partners.

Knowing when to skip a generation and when to switch from one partner to another, can really make a difference. Making the right decision on hardware platforms, on operating systems, on databases, and on systems and network management is crucial to building and then supporting a stable and reliable environment. Laying across this a security framework and making sure it is kept current and free of unprotected entrances and then making sure there’s a sound business model behind a dual-site strategy that accommodates planned as well as unplanned, or disaster, outages – needs a wealth of experience and knowledge and a serious commitment of time and money to stay current.

You know, in the end, I feel far more comfortable when a group or team is involved with this responsibility. Too often I have seen individuals steering companies down the wrong path – perhaps not initially, but over time, one decision at a time. I saw a good team approach being developed at Insession and I guess this has now biased me somewhat. And the picture I have included here, at the top of the posting, is of the former Tandem DSM team that worked on the NonStop NET/MASTER program in the early '90s.

Getting this all right is hard, and getting a good team together who really do understand the “balance” between costs and benefits, equally as challenging. But the downside here is beginning to become burdensome – with legislation now on the books in many countries that includes penalties for leaving personal data unprotected and where unavailability of a service precludes timely financial reporting.

For those companies that generate revenues from their IT infrastructure – services bureaus and application services providers, card processing and switching companies, etc. – this function can be very important and vital in keeping the company competitive. Whether an individual or a team, it will depend upon the size of the organization as again, one size doesn’t fit all!

How do you motivate – like everything today, this has as much to do with the engagement of the group or individual as anything else. By this, I mean, the people in this field have to be a part of the action and be visibly recognized with any success – this is not an ivory-tower position any more, but one where communication and people skills are just as highly prized attributes as technical prowess. Folks who just can’t communicate and motivate are not suited for these positions in the future. Motivation comes from a series of little wins, of small battles won well, and it’s up to the senior execs of these companies to encourage them with early goals that can be achieved. I don’t know of anyone in the user world pursuing the grand deployment anymore.

Talking to Peter and Neil brought it all back to me. There’s no substitute for professional management – folks who have had the opportunity to develop the skills that are so much in demand these days. I am seeing the role of the CTO becoming less executive and more hands-on, operational. Indeed, I am seeing user companies assigning the role to folks that are really tuned into the ever-changing technology landscape and who themselves understand the investment in time this all takes. And in the months ahead, I will be looking at many of the senior roles present in our organizations and at the value they provide.

So, will we see the role of the CTO within the user community simply fade away being replaced by a Technology Leader, whose team is directly involved in progressing technical developments?


Anonymous said...

I agree with the importance of being "hands on"... in addition to CTO's, the concept applies doubly to architects. Too much "Ivory Tower" is a very bad thing.


RT Writer said...

Anonymous (Sam) - I totally agree with you here. It's not just those responsible at the very highest level, but across everyone charged with setting an "architecture direction". I plan to revisit this topic from time to time - and look for more feedback from the ITUG community. I am also looking at the future of CIO's as well - as we see a number of them being pushed back down the hierarchy and ending up reporting to the CFO.
Again, my own experience suggests that the best solution for architecture and technology may not be just a single individual any more - a team leader, for sure, but a small group of folks who maintain close ties to the "mechanics" - the hardware, software, tools, etc.

Anonymous said...

IT Manager - I agree with Anonymous (Sam)however, what we do see through my research that I have done is that just as we have architects that design buildings and oversee the construction there of we will get architects that will design systems and oversee the building there of. I further saw that the CTO is becoming a function and not a title. There are companies that still maintain one Person with the Title but a number of companies create a CTO function. As the architect of buildings work close together with the construction company so the architect of systems will have to work closely with the builders / developers of the designed system. The ultimate goal is the three letters FBC. Systems need to be built Faster, Better and Cost effective and this is the challenge of the architects.