Friday, November 29, 2013

Let's Build a Smarter Planet - Part II

This is the second part of the transcript of a lecture I recently gave at the University of Birmingham in the UK.
 
In Part I of this set of four posts I tried to give you a flavour of what IBM is and what it is trying to do to make our planet smarter. So I hear you ask, what do you actually do towards this effort? Well I’ll tell you what my job entails but first here's an apocryphal tale.

During my last year at this university (1979) I took a module in astrophysics. One day I was sitting with my tutor and he somewhat randomly asked me how much data I thought the world would ever need? Bear in mind that at this time the web, in the form that Tim Berners-Lee envisioned it, was still a good ten years away and Facebook, Twitter etc even further off than that. Rather randomly I thought that probably the most data you would expect to store would be the personal details about every person on the planet (so basic personal details plus financial details etc) and maybe the same again for companies, government departments and other institutions. Say 100 KB of data per person and 1 GB per institution.

So, by my reckoning assuming there were around about 5 billion people on the planet back in 1980 and 1 billion institutions that would equate to 1 billion x 1 GB plus 5 billion x 100 KB or 1.5 TB of storage and that would have been all we needed, ever!! How wrong can you be*?

Now, incredibly we create 2.5 quintillion (that's '1' followed by 18 zeroes) bytes of data every day. That’s 170 million times more data created every day than I thought would ever be needed back in 1980! There can be no doubt we live in a world that is awash with data.
Some commentators have said that data is the new oil and there to be exploited and commercialised in an endless number of ways. How do we make sense of this sea of data?

So why am I telling you all of this and what has it got to do with what I do? Here’s what I believe, as Nancy Duarte the American writer and entrepreneur says:  
“Technology is meaningless until you understand how humans use it and benefit from it.”
My mistake back in 1980 was not understanding how humans would embrace technology over the coming decades and use it in ways then completely unimaginable. I was only thinking in terms of my 1980's 'box' where data was largely text based and restricted to what computers were then doing with information, not what they could do with it.
 
And that’s the key thing about the role of a software architect, at least in IBM. It’s about helping people understand technology and help them use it in new and interesting ways that is beneficial to them, and hopefully the planet. It’s about how to connect people with information.

Here’s the formal definition of an architect from the Institute of Electric and Electronic Engineers.
"[An architect is] the person, team or organisation responsible for systems architecture."
 No offence to them but pretty boring and unclear I’d say.

Here’s what Rob Daly thinks an architect is.
"ar-chi-tect  \är-ke-,tekt\  n. One who believes that conception comes before erection."
He is of course right. One of the things an architect needs to ensure is that you don’t rush to the wrong decision about how to build something. A great many projects have failed because they have been ill-conceived or planned. These can have disastrous consequences as seems to be the case with President Obamas new healthcare insurance web site.

So what do architects really do? A couple of years ago myself and a colleague from IBM wrote a book on this very subject and here is a list of the capabilities we believe architects need.
  • The architect is a technical leader: As well as having technical skills, the architect exhibits leadership qualities. Leadership can be characterized in terms of both position in the organization, and also in terms of the qualities that the architect exhibits.
  • The architect role may be fulfilled by a team: There is a difference between a role and a person. One person may fulfill many roles. Given the requirement for a very broad set of skills in an architect, it is often the case that the architect role is fulfilled by more than one person.
    The architect understands the software development process: Most architects will have been a developer at some point and should have a good appreciation of the need to define and endorse best practices used on the project. More specifically, the architect should have an appreciation of the software development process, since it is this process that ensures that all of the members of the team work in a coordinated manner.
  • The architect has knowledge of the business domain: As well as having a grasp of software development, it is also highly desirable (some would say essential) for the architect to have an understanding of the business domain so that they can act as an intermediary between stakeholders and users who understand the business, and the development team who may be more familiar with technology.
  • The architect has technology knowledge: Certain aspects of architecting clearly require a knowledge of technology and an architect should therefore have a certain level of technology skills. However, they do not need to be technology experts as such and need only be concerned with the significant elements of a technology, and not the detail.
  • The architect has design skills: Although architecting is not confined solely to design (as we have seen, the architect is also involved in requirements tasks, for example), it is clearly the core aspect of architecting. The architecture embodies key design decisions, so the architect should possess strong design skills.
  • The architect has programming skills: The developers on the project represent one of the most important groups that the architect must interact with. After all, it is their work products that ultimately deliver the working executable software. The communication between the architect and the developers can only be effective if the architect is appreciative of the developers’ work. Therefore, the architect should have a certain level of programming skills, even if they do not necessarily write code on the project, and those skills need to be kept up to date with the technologies being used.
    The architect is a good communicator: Of all of the “soft skills” associated with the architect, communication is the most important. There are a number of dimensions to effective communication, and the architect needs to be proficient in all of them. Specifically, the architect should have effective verbal, written and presentation skills. Also, the communication should be two-way. The architect should be a good listener and observer also.
  • The architect makes decisions: An architect that is unable to make decisions in an environment where much is unknown, where there is insufficient time to explore all alternatives, and where there is pressure to deliver, is unlikely to survive. Unfortunately, such environments are often the norm rather than the exception, and successful architects acknowledge the situation, rather than trying to change it. Even though the architect may consult others when making decisions and foster an environment where others are included in the decision-making, it is still their responsibility to make the appropriate decisions and these are not always proven to be right. 
  • The architect is aware of organizational politics: Successful architects are not only concerned with technology. They are also politically astute, and are conscious of where the power in an organization resides. This knowledge is used to ensure that the right people are communicated with, and that support for their project is aired in the right circles. To ignore organizational politics is, quite simply, naïve.
    The architect is a negotiator: Given the many dimensions of architecting, the architect interacts with many stakeholders. Some of these interactions require negotiation skills. For example, a particular focus for the architect is to minimize risk as early as possible in the project, since this has a direct correspondence to the time it takes to stabilize the architecture. 
One of the things I think you’ll notice from this list is that actually very few of them are to do with technology. Sure, you need to understand and keep up with technology but you also need these other attributes as well.

*As an interesting aside the cost of 1GB of storage in 1980 was $193,000, it's now around $0.05.

1 comment: