Principles & Requirements

I had a role as Chief Architect on a large UK Government project. The project was in dire straights prior to my joining with significant projected cost overruns in the order of tens of millions of pounds. Investigating why we were failing lead me to only one conclusion - Requirements.

As an architect it is often easy to point at the requirements as being the source of all your woes, however; in this case it was definitely justified. We had multiple requirements teams gathering requirements from the customer in different ways, documenting the requirements in Use Cases (in different ways) - I wanted to scream - leaving the customer completely unclear what they were asking for and what they were required by legislation to do. When we started to look at the costs within the project we could not even identify the source of the requirement. [I'll get onto this soap box in another post...]

When I sat round the table with the Programme Director trying to identify a strategy to get us out of the mess I realised that the PM team could not grasp the importance of Architectural Principles. This lead me to think about how we were communicating them to our stakeholders. I hit upon this simple phrase:

When identifying an enterprise solution we take into account the business (functional) requirements and non-functional requirements but also the constraints [principles] on the solution. Changing the requirements or changing the constraints can affect the solutions and their costs.

The Programme Director understood, and the PM team quickly followed, the "solutioning challenge". I've now used this approach on a number of subsequent projects and find the PM's quickly understand the importance of exploring the constraints (principles) to see what options there are to stretching them. This got me thinking about how we should capture and document Constraints or Principles within an Enterprise Architecture...

Constraints could be loosely categorised as weak or strong. A weak constraint being one that is easily challenged and overcome, having little business benefit to the solution or the Enterprise. A strong constraint is one that is difficult to challenge and one you unlikely to overcome for a number of different factors.

Some examples of high level constraints [nee Principles] would be:

• Business Strategy
• Defines where the Enterprise would like to be
• A strong constraint
  
• Architectural Strategy
• Tactical solutions or approaches are often taken if they are perceived to be cheaper or easier to deliver to the deadline reverting to the AS-IS Architectural Policy
  
• A weak constraint unless the solution was key to the business strategy
  
• Architectural Policy
• Defines the constraints within the current AS-IS Enterprise Architecture
• Products, Technologies, Approaches
• A weak constraint, but may require considerable effort to introduce new products or technologies onto the estate.
  
• Security Policy
• Defines the approach to Security within the Enterprise
• Has far reaching consequences into the Enterprise and often shapes the AS-IS architecture
• A strong constraint

An example Security Policy [Principle?] could Enterprise conformance to the UK Government Security Guidelines. This policy/principle/constraint could introduce significant cost into the solution; removing the cost by challenging the constraint can only be done with good understanding of the risks that may be introduced into the Enterprise. Acceptance of any change to this constraint is going to be a long drawn out process that could significantly affect the timescales without any guarantee of successful change.

So bringing us back to the original "solutioning" challenge:

• Within an Enterprise Architecture (EA) there must surely be a generic set of requirements sourced from the Principles underpinning the EA that should be applied to each new programme or project
• EA Governance should be measuring compliance of solutions against these requirements
• If an EA has an architectural requirements catalogue then specific areas of a constraint could be challenged when costs can be clearly attributed to the requirement
• Having a specific challenge to a part of a constraint should significantly reduce the architectural effort required in exploring or stretching the Enterprise Principles [Constraints!]
• The EA Requirements Catalogue should be a major tool in explaining to the business stakeholders solution options and costs

So when you're on a programme or you've been engaged to help with the Enterprise Architecture have you been able to understand and communicate the constraints of the business and architectural principles? Have you been able to have traceability of solution costs back to the constraints? If so, how have you achieved this?

Cheers,
Andy