Anith observes that "an application can trespass on the field of data management" and that developers sometimes "treat the database as being a mere component of the ‘application domain’".  Particular skills and experience are required to manage data and to create and maintain databases.  Data management differs on at least two levels:

1. At the programming level, being able to write an SQL statement is not the same being able to design a database.  The set based thinking required to develop design a database effectively is very different to the procedural thinking required by most programming languages.
2. Databases have a different life-cycle to applications and they are often shared between applications.

In my previous blog, Vive la différence, I stated that we do not train people in design.  I think this is a illustration of this point.  We often don't teach an understanding of data management and its approaches.  This results in designers and architects having a poor understanding of the role of databases in the application landscape and people like Anith having to pick up the pieces.

We had a number of technology capabilities that could be implemented as customisations to the package, were provided as add-on modules or could be bespoked.  My aims were to keep the IT and commercial landscape as simple as possible, keep license and delivery costs downs, and minimise timelines.  This would drive me to a default decision of using the add-on modules.

We would be outsourcing the implementation to a tier 1 consultancy. As part of our implementation partner selection process, we asked them to provide feedback on the viability of this approach and to highlight any risks with their mitigations.  There were several modules that our five potential implementation partners had told us were “high risk”.  It was interesting that different modules were highlighted by different potential partners.   I have summarized their responses:

I was put under pressure by the business to accept these recommendations because these vendors were the “experts”.

I wasn’t very happy with these responses.  I wanted to understand exactly what didn’t work, what was unproven in the market, if there were technical or business workarounds, what the impact on the IT and business solution if we implemented these modules and things went wrong, and how should we manage the delivery risks.  We asked each vendor to give more detail to substantiate their claims.  We also talked to the package supplier, to existing users of the package and to some analysts.

I was “allowed” to delve into these recommendations further when I explained the potential cost impact of these “mitigations” which would have increased the overall business program costs by over 10%.  Plus we would have had more build and integration would have increased the timeline and increased delivery risks.  I could quantify the impact of using their solutions but they had challenged my baseline approach without quantifying the impact of the risks they had identified.

Now, let us look at each of these product “risks” in turn…

Reference data management – it turned out that some implementation vendors were basing their assessment on an old version of the module that had acknowledged scalability issues.  The new version was a well established product that had been acquired by the package vendor.  The real issue was that the implementation vendors did not have any implementation experience. The new mitigation was to require them to have training and support from the package supplier, to limit the implementation to core functionality (i.e. not to try to do anything “clever”), and to get their design and implementation signed off by the package supplier.

High volume transaction data consolidation and load – this module was not new, it had an established track record of success.  The implementation vendors had either not implemented it or had very few staff available to implement it.  Again we told the implementation vendors that they would be required to get training and support from the package supplier and to get their design and implementation signed off by the package supplier.

Demand forecasting – this module was another recent acquisition for the package supplier so again there was little experience from the implementation vendors.  However, this module did have performance issues.  We worked with the package supplier and our infrastructure suppliers to develop an architecture that would deliver our non functional requirements.  We also put some specific tasks into our implementation plan to test performance early enough in the roll out schedule to enable us to change course if necessary.  If necessary we could retain our legacy solution longer than originally planned. 

Reporting – we were referred to a number of “failed” implementations of this module.  I spoke to the managers at these sites to determine the root cause of the “failures”.  In all cases it was poor logical design.  The solutions would have failed using any technology.  It was simply poor ETL specification, poor data warehouse design, poor data mart design, and poor implementation practice.  There were no issues that could be attributed to the package modules.  Perhaps the implementation vendors didn’t want to admit that their design work had failed.   Again we told the implementation vendors that they would be required to get their design and implementation signed off by the package supplier.

Integration – the package had its own integration solution that linked all its modules together.  It was a relatively immature solution when compared to specialized products when used to link in other applications.  We judged this to be a critical threat to the program.  We decided that our approach would be two pronged.

1. We would plan to use the package vendor’s integration solution but we would put some additional tasks into our implementation plan to test performance early enough in the roll out schedule to enable us to change course if necessary.
2. We would also work on an alternative solution from an other vendor. In this case, we agreed commercials early to prevent us being held to ransom later in the program.

We went ahead with my original IT landscape, much lower costs than our vendors had recommended and a set of contingencies and risk management actions that secured successful delivery of the business benefits.

Implementation staff from the implementation vendors who have just rolled off a two year enterprise scale implementation program have product knowledge that is two years or more old.  And they are not very quick to talk about their failed implementations.

Product vendors want to get their solutions out into the market.  They also recognise that successful implementations are critical to their success.  You have power over them to give enhanced support if you are going to implement any new features.

A lesson of my previous post is that when you work with analysts you need to understand their methods to get a good understanding of whether they really have a solid grasp of the subject that you have engaged them to advise on.  The information gathered about the success or failure of solutions will be based on projects started two or more years ago with previous product versions.

So who were the experts?  We were! It was our business, our change program and our IT landscape.  We had to invest to learning about the product releases that we would use.  We had to be incisive in our questioning of the “experts” and to attempt to understand their agendas and biases.  We had to be brave enough to make our decisions rather than take the easy way out and take the consultants’ and analysts’ advice.

The first blog was written by Leo de Sousa and this had the title of What good looks like – follow up.  He asked the questions:

• How big a project would require this level of artefact creation? For small and possibly medium projects, the work to do the architecture may be more than delivering the project.
  • This is a good point and I should have made the context clearer.  I am not assuming that the artefacts exist as project artefacts but just that they exist.  They may be at enterprise, line of business, program or project level.  In the context of a project, I just want the information.  My opinion is that this information should be created at an enterprise or line of business level and updated by projects and support teams.
• Is there a subset of these artefacts that would be sufficient for small and medium projects?
  • No!  A smaller project will have fewer decisions, fewer deliverables and therefore the information produced will be less.
• How would the next solutions architect find and assess the artefacts created?  Need a searchable, secured repository - wiki?, blog?, SharePoint?, network file share?, knowledge base?
  • It doesn’t matter so long as architects, analysts, designers, developers, testers, etc can find what they need when they need it.  All of those approaches listed can work with the appropriate implementations and disciplines and they can all fail.
  • The key to this is not the repository, it is in most organizations the “business as usual” support team.  They are the long term custodians of the IT solution and its relationship with the business.  They keep the knowledge up to date and are responsible for handing that knowledge on to development teams when major changes are required.  Ideally this is well supported by sound processes and tools and not critically dependent on individuals. 

He went on to make the points that the key factors for success are:

• ensuring that there is time for solution architects and enterprise architects to work together to do peer reviews: 1) pre-project, 2) technical reviews in a project and 3) post-project
  • I absolutely agree and I find that this is one thing that can be  very difficult to achieve.  Enterprise architects tend to be in short supply and have to ration their time.  Solution architects often do not take an enterprise view and fail to highlight critical enterprise architecture issues. A good triage process addresses the issue of rationing. 
• communication of agreed upon standards and principles is essential to build a common language
  • The standards and principle help address the second issue and educate solution architects on the issues that are of enterprise significance.
  • I would go a little further, we also need common goals and an agreed approach to making rational compromises to help solution architects make the right decisions and recommendations.
• negotiating with functional managers to ensure time is allocated to every project for architecture
  • This point is very important.  It is easier where there is a recognition that the landscape will change significantly.  It is equally necessary where the project extends an existing capability. 
  • In any significant project there is the potential that a requirement will “break” the architecture (the break could could be in the business, applications, data or infrastructure).  My approach to ensuring there is architectural effort has been to ensure that the project has enterprise and long term requirements captured to justify the “extra” effort.
• regularly demonstrating value to the organization by taking an enterprise, long term view
  • Every project has an enterprise and long term context.  The key is to identify the stakeholders and requirements to express this.  Then demonstrating value becomes meeting stakeholder requirements.

The second blog was by Nick Malik and was entitled Why good doesn’t happen.  He states that “there is a flaw in the logic” and the “advice is incomplete”.  He examines my list of 10 artefacts (or 14 as he appears to prefer) from the perspectives of :

Viewpoint 1: at the beginning, looking forward, defining project requirements

Viewpoint 2: in the middle, looking back, trying to understand

He goes on to make the following points:

• If I create an artefact “for the future” that does not mean that the people, in viewpoint 2, will use it.  He states there must be a design process that mandates that the artefact be used. 
  • The existence of a process today does not imply the existence of the same or any process in the future (the reverse applies too) so I am not sure that this point helps us much. 
• If there is not such a process then the artefact should not be produced because there is no business justification.
  • The business justification is simply based on hard experience which tells me from past and current projects that I need this information to take cost, time and risk out of making significant changes to an existing solution.  The project or program, through its governance process, is at liberty to de-scope these proposed deliverables.  But, in the interests of making a fully informed decision, it is passing on cost, time and risk to the next project.
• In the context of the maintenance process, we should “draw the requirements for documentation from that development process… not from a wish list.”
  • To be clear, the selection of artefacts is mine based on my experience of making large scale changes to existing architectures.  It is not the “wish list” of an enterprise architect imposing his views on developers.
• The artefacts identified form “some tiny part of a much larger ecosystem of information”.
  • I absolutely agree.  The management of this eco-system is another subject.  My preference is that we approach this using a federated approach that puts responsibility close to the point of consumption but also ensures coordination where necessary.

Finally, he makes the following suggestions as to how I should complete my advice:

• The artefacts “need to be findable, consistent, and AUTOMATICALLY linked together in a way that minimizes the “archaeology expedition””
  • This is a worthy aim.  In many organizations this is a distant dream – perhaps a fantasy.  If we are not on that road, I think we should do something today that makes things better, let us just have some information.  And that is what I have tried to describe.  I believe that the issue of inconsistent and out of date information is quicker and cheaper to solve than the problem of no information.
• “The data describes part of the architecture of the enterprise, and as such, needs to be maintained at the enterprise level, for the sake of engineering.”
  • It does not need to be maintained at enterprise level.  It needs to be maintained where it has value to be maintained.  It needs to be consistent across the enterprise where consistency has value.  We should only engineer to the level where the engineering adds value and no further.  I do not see the need for monolithic centralised approaches that require huge uninformed, unaccountable bureaucracies to operate.

However, convincing people that there is a problem and that an alternative approach is better can be difficult.    The project or program has a momentum that is carrying it towards the creation of an expensive and avoidable legacy.

Before we consider what you should do let us quickly clarify what not to do!  DON’T…

• Get angry– it may be frustrating but you must be seen to be calmly working in the interests of the business.
• Get negative – you must be seen to be passionately behind the business goals.
• Don’t waste your ammunition by putting forward weak unsubstantiated arguments. 
• Appeal to abstract architectural principles – while they may make perfect sense to architects, generally no-one really cares!  (This may appear to be heresy – but I will return to this)
• Lose credibility.

Now let us look at how to move forward…

The first point is that within a project you don’t normally have much time.  You must be focused, effective and efficient in substantiating your gut instinct, preparing and delivering your argument to the right people, and getting a project to reconsider its course.

Step 1: Determine your goal

Find out when key decisions are taken, when the project becomes committed to a course of action (e.g. contracts get signed, resources are assigned, work starts, announcement are made, egos are on the line).  This determines what you can achieve:

• You don’t have time to understand the issues fully – your aim here is to make sure that decision makers have “wiggle room” and can change their mind at a later date rather than force through a bad solution.
• You have time to frame the problem and present it to the right people – your goal is to persuade them to create time and make resources available to find the right way forward.
• You have time and access to the resources you need to prepare a solution and get backing for it.  This is rare ideal where you can be the leader.

Step 2: Understand the business drivers

Its all about benefits… what are they? Are they increased revenue, reduced costs, keeping up with the market, reputation protection, risk reduction, regulatory or statutory changes?  When are they due to be delivered?  What has been promised to investors?  Are there any regulatory or statutory deadlines?  Whose ego is on the line?

The business case for a project is the obvious place to look.  However, business cases should paint a prudent picture and are written to overcome a hurdle in the investment process.  Expectation could be significantly different, there may be other hidden or implicit or intangible benefits that are much more compelling to the key stakeholders.  Understanding the business sector and the stakeholders is key to getting a full and accurate understanding of business drivers.

Timing of benefits delivery is often a major driver for compromise.  If your proposals are perceived to reduce the level of benefits or put the timing at risk, then you will probably lose credibility.

Step 3: Understand which business drivers are threatened

I was lead architect for a project where we were introducing a new channel for a client.  I felt very uncomfortable in taking the current architecture forward but I couldn’t pin point why.

The simplest solution to introduce the new channel was to extend the current solution.  However, it felt like functionality was incorrectly distributed between applications and we would be making things worse.

What I needed to do was to identify the impact on the business drivers.  I knew that the client was growing this part of the business but there was no clarity over how it would do so.

I knew how the application should have been built, I new how I wanted to take it forward.  I could only make a vague case about enabling future business flexibility which would add cost and risk to the current project.

I managed to find a stakeholder, after much enquiry, who was prepared to very forcefully articulate the future direction of the business.  He wasn’t particularly senior, he was not a key decision maker, but he was respected and influential.   He was very interested in the threats to this future and was prepared to sponsor a rethink.

I struck lucky which enabled me to challenge (via a proxy) the accepted thinking and get rational compromise to be made and a longer term roadmap to be developed.

If you can’t make the case, then you have to accept the solution as is and move forward.

A word on architecture principles…

Each principle should have a rationale that is clearly based on business needs.  If a solution violates a principle then look to the rationale to identify the business imperative that the principle is designed to support.  While the principle may not interest many stakeholders, the underlying rationale should do.

Step 4: Understand the stakeholders

Architects often raise concerns where the longer term flexibility of solution has not been thought through or where a solution appears to cause problems in another area of the organisation. 

As a solution architect, your responsibility is to ensure that the right solution for the organization is defined.  “Right” is defined by the “business” – however, the “business” is an ambiguous concept.  The justification for all architectural decisions must be “to meet business requirements”.

The key to resolving the architectural concerns is to involve all affected stakeholders in the project and ensure they express their requirements for the longer and shorter term.  If you have all the key stakeholders who will be affected by a project in both the short and long term then you will be able get requirements, constraints and directives that provide the business rationale for architectural arguments.

Obviously, to get requirements from stakeholders you need to know who they are.  If you already have a network of contacts then this will be easy.  If you don’t then you will need to find some allies to help you identify key stakeholders.

With business requirements to back your arguments, you can give the program or project manager the “wiggle room” they need to start to change the project remit to take into account architectural concerns.

If you can’t get the business backing, then you have to accept the solution as is and move forward.

Step 5: Address objections

Sometimes there is push back that states “this is scope creep” or “this project is for XYZ business unit” or “we haven’t got time”.

Scope is best dealt with by specifically de-scoping requirements with knowledge of all requirements and an understanding of the implications of de-scoping.  The de-scoped requirements allow others to take appropriate action with the knowledge of the project.  It enables a roadmap to be developed to address de-scoped items.  Refusing to collect requirements is not a reasonable approach.

Limiting stakeholder involvement based on who the sponsor is or which business unit has get the major benefits is also not reasonable or wise.  Proper stakeholder analysis is essential and all affected stakeholders should be invited to contribute requirements.

Time is a legitimate concern but the reality is that only a small amount of time is required.   Architectural decision making normally requires high level direction across a broad area and perhaps more detailed requirements for small but critical areas.  Key people can be seen on their own at time to suit them.  You don;t always need workshops, it is amazing what can be achieved in 15 minutes if you try!

Step 6: Drill down on the business impacts

The initial "gut instinct” about the solution that caused your concern should now be expressed as requirements that are at risk.  They may be:

• non-functional requirements about performance, scalability, security, reliability, etc
• business requirements relating to future proofing, broader business areas affected by the project, downstream project dependencies, etc

You will need to understand the benefits of achieving and the impact of not achieving these requirements.

Step 7: Frame your initial solution options

Your solution options should include:

• The original baseline option that you were initially uncomfortable with.  In addition, you will need to develop an outline roadmap that delivers the additional needs.
• The ideal option, this will be perfect design that you would produce if you were starting again.  You may have to rule this out immediately if the distance from reality to perfection is too great.  But it does give you a benchmark.
• A small number of options (realistic maximum is around 3) with outline roadmaps that provide different routes to meeting the business needs or different levels of compromise to those benefits.

There should be significant differences between the options.  They may have different:

• benefit levels
• timing of benefits
• business processes
• levels of automation
• business or IT risk levels
• business or IT resource requirements
• needs for business involvement
• costs and cost profiles
• lifetimes
• components
• configurations
• data distributions
• non-functional characteristics
• interfaces
• approaches to re-engineering
• refactoring plans
• etc.

For each option a high level delivery plan with an initial assessment of business benefits and impacts with timing should be developed.

You now have the evidence to persuade key stakeholders that the program or project needs to take a step back and identify the best way forward.

Step 8: Carry out a feasibility study

All the previous steps typically have to be carried out rapidly and sometimes superficially because you may not have fully contained the momentum of the project or program.

If you have managed stakeholders and framed the options adequately then you should be in a position to investigate the identified options, identify the trade-offs, make a recommendation and develop the new solution architecture and roadmap.

Finally, Expect the unexpected

This will not go as planned.  Despite logic, decisions you don’t understand will be made.  You will never get the full story.  You will never fully understand the stakeholders and their motivations.

If you don’t get what you want then accept defeat gracefully.

Be careful.