Sunday 14 April 2019

Degrees of architecture

I sometimes find that there is a bit of confusion or fustration when it comes to Enterprise Architecture or Architecture over all.

It is often that this comes out in “The business doesn’t let me in to do analysis on their business”, altough this may be true in some cases the fundimendal question I often find myself asking is, What kind of architecture is the Entreprise needing?

There is sometime appropriate to only do Technology Architecture rather then the full stack, sometimes you need to do it backwards, start with projects /opportunities. There isn’t one structure way of doing this.

The biggest thing we as Architects (Enterprise, business, information, technology) will need to realise is the business will be in diffrent places within the maturity when it arrives on our desk, the project will be in a diffrent maturity places along with the team members.

So what do we do? 

We aim to deliver value as soon as possible, avoid analysis paralysis and do just in time deliverables. While doing this we go the extra mile and demonstrate value in other domains.

As  an example:
Working on a fairly major migration program I realised that the business was looking to me only for guidence and roadmaps on the technology landscape including risks, gaps and issues. While delivering this I used the information gleemed from the technology analysis to also produce a Business Services impact Information and this demonstrate how this technology landscape will impact the services the business offers to internal and external customers.

This allowed me to open the door to have a more meaningful conversation with the business itself on the coming changes and help them build a plan for training, communications and mitigations to the impact the migration project was going to cause.

So in summary: 

Understand what kind degree of architecture the program, business or the deliverable requires, build this value and aim to go over and above this by demonstrating other thought points and remember picture is a worth 1000 words.

Tuesday 22 January 2019

Starting Enterprise Architecture

When starting an enterprise architecture, this can be a daunting task.

* How do I get started?
* What framework should I use?
* What templates should I use?
* What should I collect?
* Why isn't the enterprise waiting for me to complete my analysis?

All of these questions are valid and understandable, however, the answer to them may not seem straightforward or the one you may want to hear.

So how do I get started?
As you may have read from may other blog posts or information on the old interweb the key to doing a successful architecture is in small influential chunks or to eat the elephant one bite at a time (apologies to all elephants).

So, start with one of your projects and don't be too strict on following one process, ensure you are agile to adapt to the speed of the project or the change. Avoid going analysis paralysis or to much detail.

The aim of the game is to provide value as soon as possible.

What framework should I use?
In short, all of them. They are all great in their own way, TOGAF, ZACHMAN (as the main ones) are brilliant frameworks, however, they are also all-encompassing and hence they all say "tailor us to your specific use".

So if you understand a process in Zachman more then you understand a process within TOGAF then use the Zachman process, use what is the best of each framework to your advantage.

What templates should I use?
For me, the answer is NONE. Why? Because you may utilise effort in getting information that is not of value to you at that point in time and therefore can drop into analysis paralysis as you gather information to fill a template.

So what do I do then?
Well, start simple and then expand. Start with a spreadsheet with ID, Name, Description as a starter for 10.

Either start from the top down, bottom up or both, whichever provides the best value to the organisation.

As an example I choose to start with both (top and bottom) as I was working with some stakeholders from strategic and planning view point and then services mangement from the technology layer view point.

So I started with simple catalogues (lists) of strategic objectives linking this to IT projects and then roadmap of services.

And again I didn't go to deep into things and just started with ID, Name and Description then expanded it when I needed to.

As an example, if I am talking to senior management they are not overly interested if the Network Services is delivered over PSTN, ADSL, Fiber they only care about is it fit for business need and is it cost effective?

Why isn't the enterprise waiting for me to complete my analysis?
There is a trap here that is easy to fall into here, where do you stop, do I go all the way from strategy to port on a switch.

Most likely reason is that your enterprise wants to get on and deliver the outcome and to do this it needs to move on the project so to gain influence and show value you need to understand what is just enough analysis. Once you have established that and built the influence from your team or management then you can start influencing the analysis phase and how much you capture.