Udostępnij za pośrednictwem

Top-down, Bottom-up...but what is the 'Middle'?

  • Artykuł

There was a recent conversation between several folks on the topic of what Top-down is versus what Bottom-up is. I think of these two terms as analysis approaches similar to the OSI Seven Layer Model which clearly describes what is up and what is down. Using the OSI Seven Layer Model as a metaphor, 'Bottom Up' would be analysis of a enterprise architecture from the physical layer and working your way up to the business strategy/goals and 'Top Down' would be analysis of an enterprise architecture from the Business Strategy/Goals and working your way down to the physical layer. Of course, the OSI Seven Layer Model doesn't aknowledge Business Strategy, but I hope you get my attempt at correlating to the OSI model anyway :).

Although I think that these two concepts are interesting, I feel that they are only a means to an end...and the end being 'The Middle'. If one could define The Middle, we could make a significant step to defining that elusive creature called business to IT alignment, or as a Gartner analyst once said business to IT fusion. I sort of like the twist of using the word fusion because it conotates a tighter relationship between business and IT and feels more like IT adjusting to the business in near-real time. Anyway, with regard to enterprise architecture, The Middle is a standard public system interface of a business software system with a clear intention of optimizing for system flexibility in the system design. The Middle, therefore, must have at least the following characteristics:

  • Clearly describe software service endpoints which automate a business process step/task/activity
  • Defines the business information/objects via a canonical message schema passed into (and out of if appropriate) the business system interface
  • Defines a published address and transport protocol of the software service
  • Is inclusive of the logical system architecture Service Layer pattern

I'm certain that there are more characteristics and over time I'll update and build upon this list. For now, I'd like to simply assert a few to get the concept out there. 

Can there be other 'Middles' such as those software services which have a standard interfaces to data, like the situation that Master Data Management solutions propose, and software services which that support Bridge or Gateway interfaces? Yes, of course! However these are methods for building high-quality software sub-systems to support the business software. So, from the enterprise architecture viewpoint and a focus on fusing the business and IT, The Middle is the business software system interfaces not lower-level standard system interfaces.

So, is The Middle an analysis approach compared to Top-Down and Bottom-Up? No. The Middle is the end game and is a result of analysis combining both Top-Down, Bottom-Up and Middle-out analysis methods. The main point is to know what you are looking for when using these approaches before using them and avoid waisting heaps of time. I would like to note that using Top-Down and Bottom-Up analysis helps with identifying traceability from Business Strategy to physical implementation that will be very useful down the road if/when someone from the business or and IT group needs a simple view for why The Middle is necessary and how it affects them.

Comments

  • Anonymous
    July 20, 2007
    Great post, Gabriel.  The most interesting sentence is this one: "So, is The Middle an analysis approach compared to Top-Down and Bottom-Up? No. " Do you feel that bottom up is an analysis approach?   I tend to view it as a spectrum: top down does analysis, design and development.  bottom up develops and hopes they are useful.  middle out does analysis and stops.   Therefore, top down and middle out are analysis methods.  Bottom up isn't in there.

  • Anonymous
    July 21, 2007
    Theoretically they are all analysis methods. I suppose the point I wanted to make was that they are all useful but if the middle isn't understood you'll never know what to analyze and when to stop therefore forcing a lot of wasted time. I'm suggesting that we need to understand and try to define as best as possible what the characteristics of The Middle are before conducting Top-Down, Bottom-Up, Middle-Out, xyz analysis. To date, The Middle is illdefined and I observe quite a bit of talk around analysis techniques that don't seem to answer the key question The Middle is meant to answer. In my opinion, that key question is 'what are the standard business system interfaces which bind the business' automated business processes to information which are stable and optimized for system flexibility?' The characteristics I started in this blog post is an attempt at describing The Middle from an enterprise system architecture perspective. I'd like to continue refining the list and driving the relatinships to lower-level system abstractions as well as defining the associations to other domain concepts such as business process, business capabilities, information data facets/entities, technology features, etc as I go.