Year: 2010

Attributes of an IT Architect

Peter Cripps architecture , ,

I’ve recently been reviewing some course material for a further education institute here in the UK to see how well suited the material was for preparing students to enter the IT industry. This made me think about what skills we as IT architects really need to have. The following points describe (some) of the realities of working in a business/IT services company as we enter the second decade of the 21st century. They are intended to act as a reality check to enable new entrants into this profession to assess their skills. In my experience these are all skills that an effective IT architect needs to master or at least be aware of.

  1. Understand Business Drivers. Cost reduction is the number one driver for businesses. IT for the sake of IT is no longer an option for a business’ IT department (was it ever, really). IT must be seen as being responsive to the needs of the business. If IT is not seen as removing cost from the business then no business case will ever (or should ever) be signed off by the board. As a consequence of this the market for service providers is fiercely competitive and when responding to Invitations to Tender (ITT) service providers must be acutely aware of this. Bids are often won purely on price.
  2. Work With Offshore Developers. As a further consequence of 1) as much work as possible is put out to off-shore, low-cost economies. This applies to most aspects of programming, package integration, web development and test. Whilst knowledge of object-oriented techniques, Java programming etc is useful it is unlikely to be a major part of the day to day work of an IT professional in a services company. Instead we must be aware of the cultural and social differences and work effectively with these folk.
  3. Understand Complex Systems Integration. Today the really wicked problems are in the area of complex systems integration (CSI). With mergers and acquisitions (M&A) in large multi-nationals occurring regularly as well as all government departments wanting to reduce costs by merging departments or systems this is a trend that is only going to increase. As a consequence understanding how to interface between systems (at a technical level) is crucial. My colleague Jeremy Caine blogs on this topic. In particular Jeremy has a nice entry here which links this and my point 5) below.
  4. Be Aware of Organisational Aspects. A further consequence of 3) is that it is not only technical integration which is needed but also organisational integration. Dealing with the points-of-view, biases, entrenched views etc of people in organisations is often more difficult than dealing with the technical aspects.
  5. Apply Processes Pragmatically. The pressure to deliver projects quickly often means that software delivery lifecycle (SDLC) processes are by-passed, overlooked or just not followed at all. Understanding how to apply processes in a pragmatic and efficient way is key to a successful system delivery project.
  6. Manage Stakeholders Effectively. Stakeholder management is crucial to effective and successful systems development. Understanding who the stakeholders are, their motivations and interests as well as how they interact with each other is a key skill for an IT services professional.
  7. Manage Non-Functional Requirements Effectively. Whilst the industry is fairly good at gathering functional requirements it is still very bad at defining non-functional requirements (i.e. the systems qualities and constraints under which it must be built and operated). IT professionals need to understand how to gather and analyse these.
  8. Understand Package Integration. The majority of systems being built today are a combination of packages, integration with existing systems and (relatively small) bespoke development. Understanding packages (e.g. from companies like SAP, Oracle) and products (such as IBM’s WebSphere Message broker) is therefore a key skill.
  9. Apply Systems Engineering Techniques. Systems are not just about software! Understanding the people, process and deployment aspects of systems is equally, if not more important.
  10. Understand Application and Infrastructure Management Issues. Systems, once built, have to be run and maintained. Understanding how to work with infrastructure providers and application maintenance providers early on in a project is therefore crucial.
  11. Be Aware of Enterprise Level Computing. Understanding the business at an enterprise-level (i.e. business and IT enterprise architecture) rather than at just the parochial system or project level is key to delivering successful IT projects. An IT system rarely works in isolation but instead needs to operate in a complex eco-systems consisting of multiple interacting systems if the propagation of more, siloed business systems is to be avoided.
  12. Don’t Forget the Human Computer Interface. In a similar way that the process is often overlooked, the effective design of the human-computer interface (HCI) is also regularly overlooked. In a business system, where interfaces are being used all day long and a few effectively designed shortcuts can literally save hundreds of hours work.

I will return to some of these themes in future blogs.

Does Architecture Matter Any More?

Peter Cripps architecture , , ,

I’ve been reading up on the whole cloud/mashups/social computing thing and the above question occurred to me. Within the context of what are essentially several new architectural styles what is the role of the architect in all of this and what exactly is the architecture he or she is trying to create? In attempting to answer this question my mind diverted to an IT architecture course that I have been lucky enough to teach on a number of occasions both inside and outside IBM. The course is called Architectural Thinking. I imagine (hope) that some people reading this will have attended that class and it occurred to me just how clever the people that created the first version of that class back in 1999 were. The key word of course is thinking. It’s not a class about a particular style of architecture, about a particular architectural process and is certainly (thankfully) not about any particular technology. The key part of that class is about how to think about problems and create architectures, often using an existing style or pattern, to come up with solutions to a client’s business problem. The main axiom being that the architecture should drive the technology and not the other way round. In other words it’s about the fundamentals that never go out of style or, to paraphrase Grady Booch:

Architectural styles come and go but the enduring fundamentals (crisp abstractions; clear separation of concerns; balanced distribution of responsibilities; simplicity) endure and never go out of style.

This course is available outside of IBM for clients so if anyone is interested in running the class get in touch with me on here.

Architecture for a New Decade

Peter Cripps architecture , , , , ,

Predicting the future, even 12 months ahead, is a notoriously tricky past-time. Arthur C. Clarke the English scientist and science fiction writer who sadly died in March 2008 said:

If we have learned one thing from the history of invention and discovery, it is that, in the long run – and often in the short one – the most daring prophecies seem laughably conservative.

As we move into a new year and a new decade the world, in my memory at least, has never seemed a more uncertain place. As the doom and gloom merchants predict an even more troubled economy and the ongoing threats from global warming, increasing pressure on dwindling natural resources and yet more wars do not make for a happy start to 2010.

Whilst solving these truly wicked problems is slightly beyond me I am left to wonder what this new year brings for us architects. According to Gartner the top 10 strategic technologies for 2010 include a number of things which we as an architect community need to be getting our heads around . Of the list of ten, there are three technologies in particular that interest me:

  • Cloud Computing
  • Advanced Analytics
  • Social Social Computing

Whilst it is easy to get consumed by the technology that these new architectural “styles” bring to the table I think the key things we as architects need to do is:

  1. Gain sufficient understanding of these architectural styles to be able to articulate their benefits (and of course their risks) to clients.
  2. Understand what the real difference between these technologies and the one that went before it are so we can build solutions that take advantage of these differences rather than more of the “same-old-architecture” in a slightly different guise.
  3. Figure out how we sell these benefits to the really important stakeholders (the RIS’s).

I reckon that in 2010 being able to identify the RIS’s and convincing them of the business benefits of going with solutions based on technology X is going to be the absolute number one priority. Most businesses in 2010 are going to be struggling to survive and not thinking about IT spends. However survival needs businesses to be both agile and also have the ability to swallow less fortunate companies as efficiently and quickly as possible. Thankfully I think the really good architects that can do this and span the business-IT gap will still be around this time next year. I’m not sure about the rest though?