How to be a better architect – what should I do? Part 2/2



This follows part 1 of this article available here.  I recommend reading them in order!

In part 2 , I look at what initial steps you can make in your career journey from “technical solution designer” to “IT architect”.


Phase 1 – Looking at what you already do in another way

How you already work can probably be formally defined as a technology agnostic framework using architecture terminology.  Unless you’ve become familiar with architecture terminology you may not appreciate the structure and rigour around what you hopefully do already. 

For example, I didn’t realise my design methodology used waterfall principles for years after I’d started using it. And , once I’d read ISO42010, I started to see my architecture reports contained views using viewpoints.  

Despite this “what you’re doing already is a good start” phase, a lot of people feel the need to replace how they work today with a formally defined enterprise architecture framework as that will improve how they work.

The reality probably is that how you work today is probably the best way for you to be working….for now, you just haven’t formally defined how you work before.

Once how you work is defined and documented – even just in diagrams created in Visio, you can then look at the gaps, weak points and areas to optimise.  For example, is most of your effort spent in the solution design phase but little in mapping design decisions to a specific business requirement – or do you skip the business requirements analysis phase altogether?

Finally, once you have how you work documented in IT architect terminology, you can describe how you work to another IT architect in a universal language you both understand.


Phase 1 Resources

Everyone has their own preferred books and articles that help them, but these are mine relevant to this phase:

12 Essential Skills for Software Architects

Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

Design, Build, Run: Applied Practices and Principles for Production Ready Software Development



Phase 2 – Changing the purpose of your solutions


The second phase I’m going to discuss is one of the hardest I went through in my transition to becoming an IT architect – respecting the fact that very few outside of the IT department have any interest in anything technical. 

The best quote that helps me remember this was someone telling me “The only person who cares about downtime is the person who pays the electricity bill.”  The only thing anyone outside of IT cares about is business outcomes and business metrics – orders per hour, £revenue per hour, website registrations per day, profitability, costs etc. 

You may start to say you have no idea how much money your system generates, how much operating your system costs, but that doesn’t mean you can’t talk about the impact your system has on business outcomes.

By the way, I’m not suggesting you change what your solutions do – just how you describe them to new audiences.


Elevator with the CEO question

If you’re in the elevator with the CEO for 20 seconds and he asks you what you do say

a) I’m designing some software to connect our web and ordering systems

b) I’m one of your IT architects

c) I help us use technology to sell more clothing

The answer jumps out at us when we read the three options, but did the same answer flow naturally out of your mind?  Of course, you shouldn’t give the same answer to everyone in your organisation, but you can start to see the change in thinking when you describe what you do to people outside of IT.

The same approach needs to be taken when we consider what the goals of our solutions are.  Could you describe anything you’ve done recently as:

  • enabling existing product digitalisation by integrating with social media
  • increasing IT’s agility by using cloud services
  • reducing operating costs through consolidation or standardisation

Those three statements might sound non-specific to you, but they’re messages that your boss and your boss’s boss will be glad to hear as they will help everyone to understand how you’re helping the business grow, not just keeping the same old wheels turning.


Phase 2 Resources

Finally, I’m going to share two useful books that helped me transition this phase, I hope they’re useful to you too:

Real Business of IT: How CIOs Create and Communicate Value

Financial Intelligence for IT Professionals: What You Really Need to Know About the Numbers






4 Replies to “How to be a better architect – what should I do? Part 2/2”

  1. Gavin,

    Firstly,a great article.

    To me enterprise architecture frameworks appear to be very waterfall focused, would you agree this has the potential to force architects to become sequential in the their thought processes or rigid in their approach? Also, how do you see the adoption of agile methodologies and thus emerging architectures changing the landscape for architects (established and aspiring)?


    1. Hello Barry,

      I think you’re right that EA frameworks, such as TOGAF and Zachman, have a waterfall style definition, but we should step back and think when that might be appropriate.

      EA frameworks should help us make “once in a generation” or “once in a major version” strategic decisions about our deployment and value of IT within an enterprise.
      While we can refine and adjust some of the outputs from those frameworks, we’d want them to be mostly right first time.
      There are some decisions we might make that we can’t easily fine-tune afterwards, adopting SOA or public cloud services for example.

      That phase of an environment’s architecture definition should be very different to tactical IT design and innovation where we may well use Agile methodologies as a way to deliver part of the value our enterprise requires.
      There’s no reason that within each phase of an EA framework you can’t take an Agile approach; however, an enterprise architect should always be making sure there is enough defined before they move on to the next phase of the architecture.

      They’re my own thoughts about your comments, I’m not sure if they help?



  2. Hi Gavin.

    Thanks for the response and your thoughts.

    It makes complete sense what you are saying, the relationship between the EA framework and the delivery methodology is similar in essence to the relationship between programme and project management.

    I think the biggest challenge as you say is the mindset shift from a techy with vague business awareness to an equally focused business and technical professional.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s