Architecture Track Record

Running Architecture

As Chief Architect for a telco we were faced with the challenge of leveraging the 40 architects such that they were able to support numerous projects and activities across retail, wholesale, networks, mobile and corporate space. Architects were often viewed as inactive observers or "consultants" who were not useful for cutting code or practical help.

The approach taken, after determining the talents and skills of the individuals, was to organize them around 3 different roles:

1. senior strategic architect for an area, who was to advise the CIOs on system design and high-level solutions
2. solution architect, specializing in a particular area and able to cut code, lead technically and sit in (a number of) project teams productively
3. lab architect, whose job was to develop reference apps and train developers in the best way to achieve a good architecture.

Lessons learnt

• Walk the Talk. This approach worked a treat, since not only were the architects now hands-on, but they were also qualified in the technology they were recommending, at the code level.
• Show me the Code. The senior architects were able to back up their system strategic proposals where necessary with examples from the lab, or at least with the confidence that it was not just "boxes and arrows"
• Garner Respect. Team members benefitted from the technical leadership of an experienced solution architect, and the respect between developers and architect could grow. Both could learn from each other now
• Aspire to Architecture. The career route both into and within architecture had some shape and meaning



Application Engineering

We set up a new application engineering department as a facility to build and promote good solid assets to be used by other projects (particularly web, but also the service layer).

These were the assets that represent common products and data transformation, presentation layer libraries, utilities and wrapper code. The idea was to follow the DRY principle (don't repeat yourself) and try as much as possible to re-use well-written and tested code to reduce the time needed on a project.

We successfully set up the org onshore and offshore, defined the processes and operational model, and delivered some quality assets.

The idea, although a new one (bridging architecture and projects) was replicated in the infrastructure space, to bring deployment also closer to projects.

Lessons learnt

• Build What is Needed. There is no reason not to custom-build a new organization, if it makes sense for the business
• Quality Will Prevail. The high quality of the assets produced proved their value, and also the value of automated regression suites. It meant they were used, and that the project did not have to re-invent the wheel.
  
• Engineering is Powerful. Code engineering, separate from project work, is extremely valuable as the delivery arm of Architecture. In the same was as we created the "Lab" previously, this org underpinned the guidelines of architecture with real code
• Projects for the Business. The projects could now focus more on building new functionality, and not on re-doing complex code that should already work, but which broke because some method was not corrently tested and hardened.
  

Reference Architecture

This engagement was all about building a reference application that demonstrated the design put forward by the enterprise architect for web.

An application was built in Java, utilizing Spring 3.0, Spring MVC, Webflows, AOP, Security as well as Google Web Toolkit, JQuery and Tiles.

This was used to demonstrate correct use of those technologies in other web projects, and to provide the initial step

Often projects do not use newer, better, technologies because they are too "risky" or because the developers on the team are too unfamiliar with it. With this approach, it was possible for the developers to get pre-knowledge, study the code and decide for themselves how difficult it was.

Lessons learnt

• Can't argue with Code. Architecture always benefits when real code is written to turn the "boxes and arrows" into reality.
• Cheap but Valuable. This was low-budget work, but could potentially save a project much more by providing the leg-up to use better technology
• Can't Argue with Code. Part of the job involved communicating with technical leaders and top developers. The only way to win respect is to show real code, even if it gets improved by them!
• Can't Argue with Code. This kind of work could be given to a good developer on commission by enterprise architecture, and as a reward for good project work: it results in the developer being trained, and architecture becoming more credible