Its been a full year since I took on a complete Architecture role. Previously I'd been an Architect / Development Manager / Project Manager. Stay in development long enough and you'll end out taking a path away from 'straight' development into a speciality or more focussed specialisation.

A few things have taken me by surprise in the last year in terms of the specific change to a pure Architectural role. One of these is the Governance angle.

What is Governance?

Good old Wikipedia has a pretty extensive article on exactly what Governance is here: http://en.wikipedia.org/wiki/It_governance but that doesn't really explain what it is in practice.

So I always knew that being an Architect (of any of the disciplines 'IA,TA,EA' etc) would involve quite a lot of discovery and design work. But I had not anticipated just how much of a Governance role it involves. Designing and communicating technical specification is pretty standard legwork, but without the added angle of Governance on top of it what you are essentially doing is 'recommendation' over management.

In real terms day to day Governance within a large organisation takes the form of both project aligned IT direction and an overall company wide IT strategy view. By this I mean that as an Architect we have to ensure that whatever is going on within the company aligns to the overall Architectural principles and core strategy that have been stated by IT Management. We are in effect 'policy enforcers'.

This is an incredibly empowering role to fill within a project / company. It often means that you are the last person to sign off on something, or viewed as the key decision maker. This also means you are often the person that says 'No' to something.

'No. is a tricky option for ex developers turned Architects. Personality wise I'm a bit of an enabler. I think IT allows businesses to accomplish their goals effectively and more often than not I'm pushing the scope of what was requested to try and increase the options IT systems provide. Saying no goes right against this principle, so more often than not 'No' is often followed by several other options. Never appear to be a block, a dead end, to something, you'll soon probably find your business support disappearing.

The scale of this Governance role has been the biggest surprise. It has certainly given me a different view of 'in practice' Architecture roles. If you aren't shy about shaping company wide decisions and enjoy technical process then I'd recommend looking into Architecture as a role.

Next time I'm talking about stakeholder management, which has also been a journey of revelations.

I've recently been discussing some of the aspects of Agency life with friends that have moved into that kind of environment and having some experience in it myself I thought I'd comment on what I consider to be some of the major differences between Agencies and more traditional working environments.

I found it quite an interesting, if challenging transition when I moved from a 'normal' office environment into an Agency space. There are several key differences that result in a distinctly different atmosphere. I think it's a combination of these differences that lead to the overall difference in the atmosphere and working practices.

For this first article I'm looking in more depth at the product and pricing models.

Products:

If you take a traditional office based working environment, the product they sell is a tangible, physical product or service. They occupy a specific market place, with a clearly defined remit and product to market and sell. This means they are an easily identified quantity. Think of the companies you know, at a brand level. Chances are you also know their associated product set.

For example:

Cadburys = Chocolate products
BT = Telephone products and services
GSK = Pharmaceuticals

There is a pretty clear relationship between the company and the product set / service. This leads to a situation internally where everyone is clear on the company vision, and more importantly knows what they are selling. It is clearly defined.

Now take an Agency model, where the product they are selling is themselves, and the services they bring to the table. This is a lot more ambiguous than a product set, and also results in quite a heavy marketing focus on the company as a commodity. I lost count of the number of times there were guided tours around the office that were trying to establish various individuals as credible experts in their field.

Think about that key difference for a second. When you go into the supermarket and pick up a product off the shelf you don't ask to see the product designer's credentials before you make that purchase, you are confident that the product is fit for purpose. In an Agency you are constantly selling yourself.

Pricing:

Consider the other side of the product 'Coin', the pricing model. If you have clearly defined products / services then you typically also have a clearly defined pricing model. Item 'X' costs 'Y' price, potentially with additional levels of pricing scale based on premium products.

Now look at the Agency model. Typically they have common offerings based on market sector and channel. If a client wants a DM campaign or a website then there are generally 'cookie cutter' processes for the Agency to go through. Obviously they don't like advertising this to clients as every client is special and receives a bespoke service (sic!) along with bespoke pricing.

The issue here is that the scope of the product varies considerably, which leads to the pricing varying considerably. This tends to be for two reasons.

1. Elements being resized during the project.
2. Some aspects of the project being prioritised over other aspects because they are deemed more important, or vice versa.

The tricky aspect to these two points is that a client has come to the Agency because they are the experts in their field. They are established best practice practitioners, and as such should be listened to. As is always the case in these things though, the people in charge of the money tend to control things. So where there is a push back on budget, the scope tends to change. Its at this point that the less tangible aspects of a project, often the most crucial aspects in my view, tend to get downsized or dropped altogether.

For a client it is very obvious to see if a graphic designer has built a header banner on a page. It is a large visible element, that to them justifies financial outlay. It's tangible. Look at the less tangible disciplines of Information architecture, User Interface design or User Experience planning. You cannot 'see' any of those project elements. Yet they contribute considerably more to the success of the project than the font choice or banner imagery.

This is a common conflict within Agency life. The push from the client to reduce the budget, but not the scope, and the push from the Agency to deliver on time and to budget, whilst accommodating (and compromising) on principles of the project.

This was the situation I found myself in frequently. Being an expert in the field, but being driven to compromise things you know, and have communicated, would affect the successful outcome of the project. Due to financial aspects that really shouldn't be up for discussion in the first place.