Enterprise Architecture IS (should not be) Arbitrary

I took a look at a blog entry today by Jordan Braunstein where he comments on another blog entry titled “Yes, “Enterprise Architecture is Relative BUT it is not Arbitrary.”  The blog makes some good points such as the following:

Lock 10 architects in 10 separate rooms; provide them all an identical copy of the same business, technical, process, and system requirements; have them design an architecture under the same rules and perspectives; and I guarantee your result will be 10 different architectures of varying degrees.

SOA Today: Enterprise Architecture IS Arbitrary

Agreed, …to a degree….but less so if all 10 truly followed one of the widely accepted EA frameworks.

My thinking is that EA frameworks all focus on getting the business goals/vision locked down first as the primary drivers for decisions made lower down the architecture stack.  Many people I talk to, know about frameworks such as TOGAF, FEA, etc. but seldom apply the tenants to the architecture at hand.  We all seem to want to get right into the Visio diagrams and boxes and arrows and connecting protocols and implementation details and lions and tigers and bears (Oh, my!) too early.

If done properly the Business, Application and Information architectures are nailed down BEFORE any technological direction (SOA or otherwise) is set.  Those 3 layers and Governance (people and processes), IMHO, are layers that should not vary much as they have everything to do with understanding the business -- from which technological conclusions can later be drawn.

I really like what he went on to say later in the post about the fact that architecture attempts to remove the amount of variance between the 10 different architect’s work.  That is the real heart of what EA is about; REMOVING THE ARBRITRARITY.


I would agree that locking 10 architects in 10 different rooms will result in some variances of solution. Its natural progression from the path to become Solution Architect or Enterprise Architect. I have a different point of view on about Arbitrary. Far too often we are focused on the project delivery (immediate need) rather than program delivery (strategic need). Now throw in the context of a fixed priced bid, and you have the recipe for postponing strategic efforts and needs until project delivery has been completed. A method to remove Arbitrary is defining and documenting evaluation criteria and weighting. This enables us to use a consistent, albeit for a single project/program/customer, method to evaluate and make decisions. As a whole, these evaluation criteria and weighting need to progress with an organization like Software Engineering Institute.

Posted by Colin Fletcher on March 30, 2010 at 04:43 AM EDT #

This discussion leads directly into the fog, (but hopefully not to any reef beyond). Even if different architects delivered different architectures it does not provide evidence that their practice is arbitrary - in any way that requires remediation, or provides a imperative for the use of frameworks. Architecture involves both analysis and design. Let's consider analysis. To be analytical a method should be well formed - enough that there is a right and wrong way to apply it. Given the same environment and the same analytical method, two architects following the method could be expected to produce the same results. However, anyone who stops to think about our current frameworks should spot pretty quickly that they are far from analytical - in the way that the Analytic Hierarchy Process is, or Finklestein's Strategic Data Modelling. Rather, what we have in our current frameworks is a set of guidelines for description. There is nothing remotely as rigorous as an analytic method in any framework. Take the two best EAs in the world and ask them to describe the same organisation using the same framework and they will produce different descriptions "..of varying degrees." Frameworks will not remove the differences in outcomes that are here being characterised as a sign of arbitrariness. More relevant though, than the confusion of description and analysis, is that this article overlooks the design element of architectural practice. In any design process there are parameters that can't be ignored. We cal these the customer's requirements or the 'brief'. If we called any architect's solution (or to-be) designs arbitrary, the only thing we could be implying is that he or she ignored 'the brief'. Anything that meets the customer's requirements is not 'arbitrary'. So formal differences in output (...of varying degrees) are not evidence of problematic arbitrariness in either the description of an as-is architecture or the design for a to-be one. And there is nothing in any framework that will remove such differences. Nor should there be. The real problem with Frameworks is that while they provide methods that can be shared and some common terms, they do not provide a rigorous 'language' (a vocabulary and a grammar) for the analytical, descriptive and design processes. One that is sufficiently powerful and complete to allow the elegant expression of all the products of these activities.

Posted by Ric Phillips on March 30, 2010 at 10:42 AM EDT #

Ric, Interesting post. Design and language are important considerations. I speculate that they are more important than the writer gives credence. There isn't just one way to architect. The strategy that architects have used to hold companies to expensive standards are now making it difficult for these companies to compete in the global marketplace. I see too many architects and IT leaders look for rules and reference architectures instead of designing solutions that affect a company's bottom line. They are turning an important job like Enterprise Architecture into a commodity that can be outsourced and performed anywhere by almost anyone. What about these two BRs? The #1 business requirement: Make the company money. The #2 business requirement: Save the company money.

Posted by Vince on June 08, 2010 at 03:37 PM EDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Art, Artifacts, and Best Practices for Enterprise Architects


« July 2016