22 April 2014
As a follow on from my post on reference architecture you can start to look at what system(s) deliver these functions. Most often there are multiple systems that deliver a certain function within an organisation. There are multiple historical reasons that cause this to happen, one of the most common ones is organisation structures that drive two areas of the business to implement their own systems to solve a similar problem. There are many more, the key is that that would have made sense at the time.
As the organisation looks at the business and such things of the cost of running the organisation and the ability to respond to change duplication is detrimental to this. If you have 2 or more systems broadly delivering the same function you firstly have duplicated costs across these systems. Also if you need to make a change to a function across the organisation then you will need to change all systems that perform this function, reducing your ability to respond quickly i.e. time to market.
In the diagram above you will note that the non-strategic systems can often be categorised in some way. The spreadsheet system is red or bad, as in get of it as soon as you can. The orange coloured systems are not strategic systems but staying on them is less detrimental to the organisation than the spreadsheet solution. How organisations deal with these classifications are many and varied.
The enterprise will often look at these functions and set a direction or target state for this function. E.g. we will move to a Strategic system that meets the requirements of the enterprise as a whole. You end up with a system that is deemed strategic. If a project is impacting this function from an architecture perspective the project should remove the function from the non-strategic (Legacy) system and implement it in the strategic system.
The big problem here is that a small project may be planning to implement a 100k solution but the cost to move to the strategic system may blow the cost out to many millions of dollars. Here we have to deal with trade-offs, architecturally we should be going in one direction but project pressures (cost) mean we may need to actually do some development in the nonstrategic system.
This now goes into the realm of architecture governance which I may skip at this point.
So as a solution architect you have a target state for in this case “Loan Origination” being the Strategic Lending System. You need to weigh up your projects ability to say move part or all of the origination function out of the Retail Lending System. This becomes a transition state and with all journeys you may need to back track a little to actually get to your destination or invest in a non-strategic system.
It is up to you to sell this to your stakeholders.
22 April 2014
In some cases an organisation has been utilising various IT systems over the past 30 years. As business problems evolve the IT systems will change and in some cases new ones will be added. Over these sorts of period of time a fairly chaotic environment can eventuate creating complexity and subsequently an inefficient architecture.
This complexity usually manifests itself in preventing or slowing down the businesses ability to respond to change in the market. Back in the day the business would be talking to the Chief Architect telling him they had to be able to sell on the internet. The problem was that their system wouldn’t be architected to support the volumes the internet would provide and most likely the thick client wasn’t suited to the internet. Sound familiar.
You find that an organisation will often produce a reference architecture that is designed to provide some guidance on how future solutions should be developed to reduce the complexity. Think along the lines of a council implementing various building regulations.
Reference Architectures take various forms but as a starting point try and break the functions delivered by technology into some logical categories. Here I have taken part of the Microsoft Reference Architecture for Banking.
The fun starts when you take a reference architecture like this and overlay the systems in use over the top of this. You often find that a function is duplicated across multiple systems and that a system is performing multiple functions which limit the ability to reuse.
So all the good coding practices that we learn as developers get violated when we look at the architecture of the enterprise. So in a sort of way we need to do a little refactoring.
So starts the journey of many transition states to get to our target state……..
4 April 2014
The learning model that has been the most use to me has been the Four stages of competence. I think part of the reason I like it is I find a bit of humour in calling myself incompetent. I am a bit of a Highlander fan and when I hear the word incompetent I remember this scene from the movie:
Tony the Hotdog Vendor: [as Tony reads a newspaper headlined: Headhunter-3, Cops-Zero] Hey Moran! Have you read what it says in here?
Lieutenant Frank Moran: You kiddin’ Tony? You know cops can’t read.
Tony the Hotdog Vendor: [Teasingly to Moran] What does ‘INCOMPETENT’ mean?
Movie trivia aside.
To learn you have to acknowledge that you don’t know something. At this point you are moving from Unconsciously Incompetent to Consciously Incompetent. This can be the hardest step for some people but is critical to start the learning process off. As a mentor this is one of my big challenges. Thankfully I often draw the Four stages of competence matrix and call out there is a long list of things in the unconsciously incompetent quadrant that they just don’t know about.
and so starts the learning process from there.
I hope you find it as useful as I do.
24 December 2013
For those parents out there they will be familiar with the cry from the backseat of the car on a big journey, “Are we there yet?” Much like children Project managers have a need to know how far we have to go and more importantly are we there yet i.e. can I mark your task as complete.
Setting out on a journey from Melbourne to Sydney it is pretty easy to know how long the journey will take and more importantly how you are progressing and a fair idea of your estimated time of arrival.
Let’s say you were one of the early explorers and didn’t have a specific destination in mind nor an idea of the terrain between you and where you were heading. Pretty hard to know how long your journey will take or how you are progressing.
Solution Architecture can sometimes be like the early explorer scenario. It usually comes down to how many unknowns there are in the problem space you are working in. Stop and think about that for a tick the length of your journey is proportional to the number of unknowns. So if I can identify all the unknowns there are I will know how big the problem is and a rough idea how long it will take to solve.
This introduces one of my favourite concepts which are known unknowns. Now the first step isn’t to turn the unknowns into knowns but just to identify there is something you don’t know the answer to. A good way to track this is to group these unknowns. You can group them into problem spaces or along functional lines depending on the type of solution you are developing.
This grouping of the solution provides a good way to communicate progress of the design activity. This can be expressed as two components:
- Unknowns that I have discovered (Known Unknowns)
- A gauge of how many unknowns you think you have discovered i.e. a percentage or traffic lights (red, amber, green)
Just be aware that the role of the Solution Architect isn’t to identify every unknown and it isn’t to turn every unknown into a known.
Known Unknows well these are the points where you do your best work. If you deem the unknown to be architecturally significant you need to get down and turn the unknown into a known and find a solution. If the unknown isn’t architecturally significant at this level of design then you just capture it but don’t need to solve it.
Unknown Unknowns well you don’t know. Looking at your solution there is a cloud of unknowns surrounding it, it is just there. You need to assess all the areas of your solution and look for weak spots, areas that the unknowns can penetrate and invalidate your solution. At these points you can do one of two things
- You either do some more investigating and identify the unknown
- Or you put a risk or assumption that underpins your design decision. Kind of like an unknown force-field.
So how does that sound as a way of venturing where no Solution Architect has ever ventured before? Pretty simple really isn’t it. Identify the unknowns that will impact you solution. Turn the important unknowns into knowns and find solutions for them. How easy could it be? Now try and get a Project Manager to put those tasks into a project schedule.
30 July 2013
I hope I haven’t had this impact on the people I have mentored?
30 July 2013
The Project Management Triangle is one of my favourite models that I find myself drawing on many occasions. As an architect you are constantly having scope discussions and while at an architecture level it may be OK it impacts time and/or budget which may not be satisfactory. This is a simple and effective way to explain why:
18 February 2013
I posted previously about the benefit of an Architecture On A Page and the benefit that it provides as an architect. Being able to socialise an architecture is an important part of the job of an Architect. You socialise your architecture so that you can understand that different people’s wants of the final design are. A tester will have a different perspective to the asset manager who will need to support the application.
These conversations and the resulting requirements, constraints etc are what my maths teacher used to refer to as my working out. Much like I needed to show my working out to a maths question it is important to show your working out to an architecture. This working out presents to people the different ways you have looked at your design and takes them down the journey you have been on to discount options and refine the architecture.
Unfortunately there is never a “perfect” architecture; it is always a set of tradeoffs that need to be made. Your ability as an Architect to make your design as good as you can and also your ability to communicate this design is driven by the completeness and accuracy of the considerations you have made with regards to the architecture.
To build this picture I refer to the technique of “collecting questions”. By this I mean that we often socialise our design with the intent of getting questions answered. The other way to look at this is to as you socialise the architecture is to listen to the questions stakeholders ask and make note of these. These questions are what form your working out. If the asset manager asks if the technology fits the skill set of his team of .Net developers and you present a java solution he isn’t going to be happy.
The Architecture on a Page is the answer to the question but you need to show your working out and to make sure you have considered everything in your architecture. To do this make sure you go collecting questions.
14 December 2012
I have had the idea of Architecture Debt on my mind of late, most designs have something in there that you could class as Architecture Debt. Mmmmmmmm
26 May 2011
A great post on how people being different can make simple tasks complex if not impossible.