Over the years, I’ve written several posts about IT architecture. Whilst it seems that there is an increasing trend to call experienced IT folks “architects”, one of my core beliefs is that Enterprise Architecture is not the same as “architecting” IT at enterprise scale. Yes, creating an IT architecture that will scale to support a global organisation with thousands of users is “enterprise scale” – but it’s not Enterprise Architecture.<\/p>\n\n\n\n
Like so many things in life, an illustration can really help describe a point. And, a few years ago, I came across an excellent Enterprise Architecture diagram from Dave Clark and Sophie Marshall<\/a>. You can see it as the featured image at the top of this post and one of the reasons I like it so much is that it’s clear that the technology is only one of several factors in a whole stack of considerations.<\/p>\n\n\n\n I adapted it (under Creative Commons) but the basic premise of the diagram remained the same – step back from the problem and understand the organisation to consider its needs and requirements. We need to know what is needed before we can can consider solutions! Then, we should ask what good looks like. Don’t just dive in with technology.<\/p>\n\n\n\n Let’s take each layer in turn… and you’ll see that, right away, I added another layer at the top.<\/p>\n\n\n\n The purpose<\/strong> is about why an organisation exists. It should be straightforward to answer but is hopefully more than \u201cto deliver value to our shareholders\u201d. A Council may exist to provide services (statutory and otherwise) to citizens. A retailer may exist to (make money and) provide the best selection of fashionable clothing at affordable prices. It\u2019s entirely logical that the organisation\u2019s culture will be strongly linked to its business motivations.<\/p>\n\n\n\n Many organisations will give an indication of their purpose on their website, or in their company report. For example, the IKEA vision, values and business idea<\/a> sets out the organisation\u2019s purpose in the form of:<\/p>\n\n\n\n Strategy<\/strong> supports purpose by providing business ambition and goals \u2013 a direction in which to head. Storytelling and visualisation are techniques that can be used to communicate the strategy so that it\u2019s well understood by everyone in the organisation. They can also help others who need to work with them (for example business partners). A useful tool for defining business strategy is the Business Model Canvas<\/a>, based on the book by Alexander Osterwalder and Yves Pigneur.<\/p>\n\n\n\n Looking briefly at visualisation, Scott Berinato<\/a> (@ScottBerinato<\/a>)’s 2016 article for Harvard Business Review on Visualizations [sic] That Really Work<\/a> stresses the need to understand the message you want to convey before you get down into the weeds. This blog post is a case in point – I want to show that Enterprise Architecture is much more than just technology. And I found a good visualisation to illustrate my point.<\/p>\n\n\n\n As for storytelling, I’ve seen some fascinating presentations over the years on how to tell a good story to bring a presentation to life. One of the most memorable was at a Microsoft MVP Event in 2017. Tony Wells used this example of how we tell stories to children – and how we (too) often communicate at work:<\/p>\n\n\n\n How not to tell a story! Tony Wells from @ResourceiT_Ltd<\/a> reminds us that storytelling is a learnt skill, which we somehow seem to forget at work! #CinderellaInBullets<\/a> #MVPBuzz<\/a> pic.twitter.com\/UHQzr6w1SB<\/a><\/p>— Mark Wilson (@markwilsonit) November 30, 2017<\/a><\/blockquote> Purpose<\/h2>\n\n\n\n
\n
Strategy<\/h2>\n\n\n\n