Principles and Implications
I’ve been doing some work recently on architecture principles and their associated implications. According to TOGAF 9’s documentation on architecture principles, implications “should highlight the requirements, both for the business and IT, for carrying out the principle – in terms of resources, costs, and activities/tasks. … The impact to the business and consequences of adopting a principle should be clearly stated.”
In the effort to define our implications, I’ve started to see two categories of implications emerge. The first is behavioral implications. These implications are functions or processes that the organization must adopt. The second is architecture/design implications. To illustrate this, use a very simple principle: standards-based. The statement for this principle merely states that all solutions must be compliant with company standards. A behavioral implications for this is that someone in the company must maintain a list of company standards. Another behavioral standard may be that the company must follow the work of standards organizations relevant to the business. An architecture/design implication would be that messaging interfaces must adhere to published company standards.
I’m finding that it may be worthwhile to explicitly define these categories in documenting the principles. One big reason is to avoid overemphasizing the architecture/design implications. It is very easy to strictly think of implications as the foundation for your assessment framework, but an assessment framework, in my experience, is typically associated with architecture and design reviews. It says nothing about reviewing the behavior of the organization, which all too frequently can be the greater challenge. For example, a reusable service may exist, but it doesn’t get used because the organization “supporting” it may see supporting other consumers as a secondary priority, at best. This isn’t a design issue, it’s a behavioral issue.
One additional thing I’m also considering is how to assess whether or not the thinking behind the implications is correct. If the rationale for a principle is that total cost of ownership will be lower, are we actually measuring whether this winds up being the case based upon our level of adherence to principles and their implications?
How would you categorize your implications? Does this two category breakdown make sense, or are there additional categories needed?
4 Responses to “Principles and Implications”
Leave a Reply
Hi Todd, interesting post, thanks.
One ‘type’ of implication that comes to mind is the notion of ‘tradeoff’ – so by adapting a principle, you may be forgoing choices or opportunities.
We can talk about what needs to happen to support a principle, but I think we should also look at what can’t/won’t happen when we support it.
In some respects principles are like a strategy – they set a direction that ties you into a subset of options/paths and are difficult to back out of quickly.
For example.. if there is some principle around ‘being agile’ – what tradeoffs might you be making in being able to esablish long term resource plans, publish product roadmaps, etc?
On a related note, something I often come up against is where to draw the line between a principle and a ‘policy statement’. Often, principles end up sound like rules, rather than statements of shared value. A statement like ‘all our services should be designed for reuse’ .. is this a rule or a principle?
Could you say, for example, that any principle that can be objectively assessed for conformance isn’t a principle at all?
Cheers
Mike
Todd,
We set our principles in two categories: our approach (which equates to behavior) and our design principles (which equates to architecture/design). The following was from an early slide in our tech deck from the inception of our company:
Disciplined Approach
– Commitment to EA best practices
– Security and Compliance equivalent to processing transactions on an ATM Machine
– Leverage knowledge of industry experts
– Minimize IT costs
Design principles
– Configurable
– Self Service
– Self Monitoring – Self Healing
– Real time reporting
– Simple Integration
I think this closely resembles what you were discussing in your post.
Mike B.:
We had quite a bit of debate on the phrasing of principles. My view was consistent with yours with the principle statement trying to emphasize the shared values. The implications attached to those principles, however, is where the rubber meets the road. These are all about policy statements, which is also a potential point of debate. It is very easy to think of an implication as a description of what things look like if the principle is followed. To me, those statements belong in the rationale, but that’s my opinion.
Todd,
Interesting stuff and I completely agree, I’d add in two other pieces I think should also be captured at this stage
Anti-Principles http://service-architecture.blogspot.com/2010/02/anti-principles.html
Non-Principles http://service-architecture.blogspot.com/2010/04/non-principles.html
Principles are the good things, but its important to be clear on what bad looks like and what you aren’t going to consider important.
Steve