Enterprise Architechtures and people I work with

I work in a company that has alot of headstrong people. really intelligent one's if i may add. and in this kind of environment... trust me, you dont want to get caught in an arguement with this guys because they wont fizzle down... everybody has his on take an everything making its really challenging to raise a point wherein everybody could agree on a definite strategy.

Arguments, answers and self-vindication would surely fly in a room whenever strong suited people start pushing their barrage of ideas... Trust me! you'll be surprise on how many scenarios, strategies and principles would flow in and out of peoples mouth and ears.

Here's something that transpired today.. the topic: Enterprise Architecture

Intelligent Programmer 1 found an aerticle in MSDN and sent it to the developers for us to read. here's what happened next

[ Intelligent Programmer 1 sends this email ]

Enterprise Architecture - made simple?

http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnbda/html/sessfin00.asp

Interesting read – to summarize:

The author maintains that enterprise architecture should be approached like war: divide and conquer.  You have a general idea about what your business is trying to achieve and then utilize/build smaller interoperable pieces to fit each logical segment instead of trying to fit everything into a huge overarching vision/architecture.  Don’t worry too much about consolidating platforms, application-level architectures, etc.; just make sure that all the systems can communicate where they need to.  Duplicate work is ok – enterprise libraries are not the holy grail; particularly since extensive code re-use, though highly touted in OOP, is difficult, if not impossible, for most organizations to get to.  Fast prototyping and a highly iterative development process (not necessarily like OOP’s iterative process since that is geared more toward refactoring/code re-use) using minimal up-front specifications is the way to get the most bang for your buck; the users see results quickly and, let’s face it, though we get detailed specs up-front, until they use it, they don’t really know what the heck they want which causes re-work headaches.

[ Intelligent Programmer 2 replies ]

Actually, I think you might have misread some of his thoughts.  I don’t think that your analogy of “divide and conquer” fits as the entire article is about partitioning and how to do it properly, whereas most people do it improperly.  It is nothing more than a modular approach to design (each module is a black box) on multiple levels/scales.  It is an exact fit for how I’ve been designing systems for the past 8 years, and it works.  Everyone should read this article and read it again if you don’t fully understand it.  Here are some of the better highlights of the article:

“An enterprise architecture is a description of the goals of an organization, how these goals are realized by business processes, and how these business processes can be better served through technology.”

“The analogy of an enterprise architecture to a city plan was first introduced by Armour in 1999 [Arm], and it is particularly relevant for today's highly complex organizations.

A city plan addresses different issues than do building blueprints. City plans address issues such as:

a.) What type of buildings will be allowed in which zones (for example, business or residential)?
b.) How do buildings connect into the city infrastructure (for example, plumbing and electrical)?
c.) What impact will buildings have on others of its ilk (for example, air quality and traffic flow)?
d.) Are the buildings built to a standard that will not endanger its inhabitants (for example, fire resistant and earthquake resistant)?

Imagine a city that included in its city plan a detailed blueprint for every building that would ever be built in the city. Such a plan would be extremely expensive to create, and, if it was ever completed, it would be inflexible and stifling. Which, come to think of it, is not unlike some enterprise architectures I have seen.”

“I'll state Boyd's discovery as Boyd's Law of Iteration:

In analyzing complexity, fast iteration almost always produces better results than in-depth analysis.”

“A relatively small group attacking a well-defined partition of the enterprise can do a reasonable job in a reasonable timeframe. A large group attacking a non-partitioned enterprise may indeed find redundancies. But the cost of finding those redundancies, arguing about how best to eliminate them, and trying to agree on a design for a unified approach will, in almost all cases, far surpass the cost of the redundancies themselves.

It is true than economies come in scale. But true economies come in small, not large scale.”

[ Intelligent Programmer 1 replies ]

The “divide and conquer” strategy really doesn’t work if you don’t know precisely what weight of arms to send where, no?  Obviously, I (and he as well, I wager) am assuming that some analysis and proper leadership/direction has gone into who should do what, where; an armored division (or a team of developers, as the case may be) thrown at the wrong enemy isn’t going to help much.

He goes quite a bit beyond advocating a simple modular approach; OOP is all about modularity but that’s not where he’s heading. I believe that he’s arguing for an approach similar to agile/Extreme Programming but more structured – constant prototyping and user feedback through appropriately controlled channels where design is based on limited initial specifications. Why limited initial specs?  By arguing for a highly iterative process, he assumes that the initial spec is NOT going to get it right – maybe not even close. That’s what the iteration are for; not for the developer’s benefit to refactor but to allow the business to refactor its requirements.  The technology and methodology used on each application are, to him, un-important – as long as each cog fits in the machine, it doesn’t really matter what the cog is made of.

Although the article is indeed about the need to break an enterprise solution into smaller, more manageable chunks; he never tells you HOW to do it and doesn’t even come close to addressing how do it properly. That’s not something he can cover since each enterprise is different.  His article is about dividing an enterprise solution into logical pieces, doling out the manageable sized pieces to small-ish teams and not sweating the implementation details.

Refer to:

“There are three primary reasons for such frequent expensive failures. The first is an over-reliance on recursive object-oriented design and analysis (OODA) architectural methodologies. The second is the false notion that creating an enterprise architecture means developing a detailed blueprint of the entire organization. And the third is a failure to break complex structures into smaller, more manageable projects.”

“A third advantage of partitioned iteration is that it ties up much less of the time of your highest-level, most critical (and most expensive) staff. This is because the design of each partition requires consensus only among the staff that are directly involved in that partition. In the recursive OODA approach, most of the staff are involved in most of the design decisions, and seemingly simple design decisions are often painstaking to conclude.

A fourth advantage of the partitioned iteration approach is that it results in designs that map naturally into an SOA. SOAs are made up of small autonomous services rather than the monolithic monsters typical of the OODA approach. These small, autonomous, interoperating services are much more amenable to reuse, collaboration, interoperability, agility, and automated workflow than their OODA counterparts.”

[ Intelligent Programmer 2 replied with this ]

He doesn’t advocate “divide and conquer” anywhere in his article, so I don’t know where you are getting that.  He does state that you need to see the BIG PICTURE, but you can break up the picture into smaller pieces.  Each of the smaller pieces do not need to know anything about the business of the adjacent pieces.  In his design and that of OOP, each piece is a black box.  That ideology is the basis of OOP.  The moment that two or more adjacent objects have knowledge of the inner workings of each other, OOP breaks.

He also explicitly is against “agile/Extreme Programming”.  One of the items I quoted from him covers that.  I really think you need to read it again.  You seem to be intermixing items that he is for, with items that he is against.  As for “technology and methodology”, he is 100% correct.  While I may have a preference for doing something one way, there is absolutely no reason for some one working on a parallel project to a similar task exactly the same way if it makes sense to do it differently.  He leaves it up to you place the partition boundaries and their level of isolation.

Anywho, I thought it was a great article.  His idea of TTV being more important than ROV is right on the mark.

[ Intelligent Programmer 1 answered]

I’m summarizing. Is he not arguing to “divide” an enterprise into manageable pieces and then “conquer”-ing those pieces individually?  It’s just an analogy!

"The moment that two or more adjacent objects have knowledge of the inner workings of each other, OOP breaks.” – that’s true. But if 2 applications were built to use the same object but one now has different requirements, then you face the choice of either changing the interface of the object or creating a new method/object for the change. All he’s arguing is that applications should be, as much as possible, completely independent of each other – no monolithic enterprise architecture.  Each application domain should be inviolate – the glue being independent services or some sort.

You mean this one: “In analyzing complexity, fast iteration almost always produces better results than in-depth analysis.”? Sounds like agile programming to me.

[ Intelligent Programmer 2 ]

Ok, if you take, “In analyzing complexity, fast iteration almost always produces better results than in-depth analysis.”, out of context I can see the misunderstanding.  That statement was in reference to a process that you write the code for, not for how you manage your programming resources.  It sort of fits into what you say in the previous paragraph too.  He was saying that it is better to write simple fast routines, than it is to write one complex robust routine that runs slower.

Whew! isn't that a mouthful? what do you think?