Principles and patterns

I have looked at these "principles" for many years and it seems to me: firstly that they are effectively constraints (almost like goals, measures of success i.e. something to be achieved ideally) and that secondly they are often opposing constraints. So that what is required in design in an understand of the trade-offs. 


This turns out to be very complex if tackled from 1st principles so in mature disciplines the idea of patterns is used which effectively encapsulate a set of principles (and materials) to suggest how something can be achieved. The seminal work on patterns (Pattern Language) reflects a practical approach in another design discipline - which also has principles.


I am not convinced that principles in their raw form can effectively be consumed and applied. They are good things that theorists like to talk about but almost useless in practice.


To use an imperfect analogy - cars one could imagine a set of principles: agility - be flexible for many purposes, go off road; capability - be able to store lots of things and people; user appeal - appeal;  speed - be fast; ease of use - easy to operate, park etc.; good TCO - economical to run; cost effective - economical to buy; etc.


But these won't tell us what type of car we want to buy or build - let alone details of a specific model. What we 1st need to understand is the pattern.  


Do we want an SUV: agility - yes; - capability - yes; user appeal - no; speed - no; ease of use - no; good TCO - no; cost effective - no.

Do we want an small hatch - agility - partial; capability - no; user appeal - no; speed - no; ease of use - yes; good TCO - yes; cost effective - yes.

Do we want an sports car- agility - no; capability - no; user appeal - yes; speed - yes; ease of use - no; good TCO - no; cost effective - no.


Our principles have not changed - but our priorities have and the patterns SUV, Hatch, and Sport car reflect this.

This comment was originally made in response to this: http://www.ebizq.net/blogs/ea_matters/2011/11/enterprise-architecture-principles-lets-talk-about-them.php#c19997

Counter-reductionist approach to requirements and projects

I like what this man Dr. Leon Kappelman says "It is the bane of applications and data to be stovepiped and compartmentalized. But that remains the standard by which we train IT and business managers" (http://www.information-management.com/newsletters/data-architecture-quality-integration-UNT-Kappelman-10021830-1.html).

He came to EA the same way I came to EA ie.

"My original focus was software development and obviously the importance of getting the requirements right. Well, it turns out that to have the requirements right, you need what you are working on in the context of the whole because otherwise you might build a great system but it doesn't create value. It might be adding redundancy or be the 73rd system to connect 72 other systems. Even if those other 72 systems are part of stovepiped business units and are perfectly aligned with them and serve their needs, as a whole the enterprise is wasting a ton of money and a ton of resources and talent."

I think it great that he identifies the problems with the “reductionist” which I had put down to solipsism of many of the technical people I have met who are interested just in their little slice of reality - their jigsaw piece. The problems are not just with technologist, but with projects in large organizations, where most operate as if the project's by itself produces business value.

I think we need to look at solutions and methods to suppirt a counter-reductionist approach. That is why we have focused on a strategic holistic approach to demand and requirements management.

EA - leadership and discipline supporting a cultural shift

MIT's Ross on how enterprise architecture and IT more than ever lead to business transformation - http://www.zdnet.com/blog/gardner/mits-ross-on-how-enterprise-architecture-and-it-more-than-ever-lead-to-business-transformation/4463

What I like about this is the clear identification of the:

• cultural shift that is required
• need for understanding through the enterprise (not just with individuals) and the identifying the limitations of the "hero" model
• need for discipline and the natural tension that needs to exist (Cf. the town planner vs the laisez faire property developer)
• difficulty of getting good adoption of and need for persistent coaching and a clear vision
• need to focus on pain points that the executive are focused on (not boiling the ocean)

Cultural shift

"... we’re learning about enterprise architecture is that there’s a cultural shift that takes place in an organization, ... and that cultural shift starts with abandoning a culture of heroes and accepting a culture of discipline."

Enterprise, not just individuals using an heroic approach

"...What companies traditionally did before they started thinking about what architecture would mean, is they relied on individuals to do what seemed best ...Nobody wants to get rid of the heroes ...What we’re trying to do is adopt a culture of discipline, where there are certain things that people throughout an enterprise understand are the way things need to be done, so that we actually can operate as an enterprise, not as individuals all trying to do the best thing based on our own experience."

Natural tension

"... the architect should be able to create a very constructive tension in the organization, and that’s the tension between individuality, innovation, local responsiveness, and the need for enterprise thinking, standardization, and discipline."

Focus on pain points

"... companies who were best at adopting architecture and implementing it effectively had cost pressures. What happens when you have cost pressures is that you’re forced to make tough decisions. ...If you have all the money in the world, you’re not forced to make tough decisions. "

"... The best architects are listening very hard to who is asking for what kind of capability. When they see real demand and real leadership around certain enterprise capabilities, they focus their attention on addressing those, in the context of what they realize will be a bigger picture over time. ...They can already see the unfolding bigger picture, but there’s no management commitment yet. So they stick to the capabilities that they are confident the organization will use. That’s the way they get the momentum to build. That is more art than science and it really distinguishes the most successful architects."

Getting adoption requires persistent coaching

While the following comments are not directed at EAMS solutions I think them apropos

"... You build something that’s phenomenally good and appropriate for the business and then you just assume, that if you give them a little training, they’ll use it well. "

" ...That’s actually been a remarkable struggle for organizations. ..."

" ...there aren’t very many companies that have come anywhere close to leveraging their platforms the way they might have imagined ..."

" ... It’s harder than we thought. It requires persistent coaching. It’s not about training, but persistent coaching. It requires enormous clarity of what the organization is trying to do, and organizations change fast. Clarity is a lot harder to achieve than we think it ought to be."

When will we learn that heroic individualism is not enough

In an presentation to EA many years ago I quoted a third party who had suggested some of the the goals were: containing costs and risks, be timely, being more adaptable and customizable and the challenges included managing complexity (which requires some discipline and semantic precision) and failing methods “Today, the most common model … is based on an approach that we call ‘heroic’ ”. Some of the suggestion made at the time were: context maps for cataloging assets and knowledge; clear methods for making decisions; patterns, business/industry reference models, default infrastructural templates or frameworks; and focusing on component topologies and interactions.

This source for this is not recent - it is an old IBM Systems Journal item in 1999 discussing architecture.

Summary

I have written elsewhere on strategies for dealing with complexity (the key being semantic precision), industry reference models and patterns (which encapsulate principles, preferred technologies, standard component topologies and interactions). This item from Ross is great in identifying some of keys to successful implementation: clear vision and persistent coaching, discipline, enterprise wide approach etc.