Archive for the ‘Architecture’ Category

Which System?

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.

Reference Architecture - Which System

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.


Reference Architecture

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.

Reference Architecture - 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……..

Collecting Questions

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.