Organizing Architecture

Except Zachman has pictures! MS wins on number of boxes, though!

Pretty, but I'm not sure what real use it is ...

My Zachman has pictures (and colours)

Except Zachman has pictures! MS wins on number of

boxes, though!

Pretty, but I'm not sure what real use it is ...

Thanks. I'm sure others may find it of use. My intention was to provide some material to those who still have questions like "What is this architecture thing anyway?" and "Why should I care?"... as well as stimulate some deeper discussion beyond how it looks. Hopefully, people will take a look at it and provide their take on how architecture can be organized.

Phil

I agree those are very important questions ... just not sure how these documents add a lot to the understanding.

OK (lets settle gentlemen).

Let me start by saying that I find these tools invaluable, and not just in software.

Building a house

==========

Lets look at building a house (stick with me please - its going to be a little long). Using my experience with the Zachman (I didn't know about the MS one - thanks for that Phil) lets image a 3d Excel spreadsheet with columns coming up from each of the boxes on the framework. The height of the columns gives you a view as to the level or "risk" associated with each box (e.g. Function (how) and Integration Architecture (Designer) - my level of certainity/risk will be the sum of at least the electrical design, building design, door ways, plumbing design, roof design - all these pieces have to "integrate" and "mold" together to produce a good house).

Now - what have I done. not only have I filled in a box, but in doing so, its caused me to think about the various pieces that go into building a house. I'm now looking at say the electics or plumbing and the various interactions that go on, there in. With plumbing in mind, I can move to the developer box and put in a "risk" that my wife won't like the taps I've picked to install (very high risk!!!) - however, I know that she won't care about the power points (low risk) because they are all the same.

Software

======

So, in software. Lets say I've just been assigned to build a new system to handle countries, states and suburbs (yep - this is one of my favourites). I can look at the (Why) - CEO, General Mgr - make money (probably). Process Owner - "it needs to fit in with other systems and use the CMMI level 5". Process worker - "the activity objective is to ensure that QLD is a state in Australia" (maybe - I'm making this up on the fly so excuse me please if I get the boxes wrong). Enterprise Arch - "EAI - use case. Actor (looks up state) uses StateService -> returns (state). Designer "state service uses state DAO on Oracle DB". Developer - I'm building this in the ABL, so I'll use AppServers and WebServices with ProxyGen".

I'm sure you get the picture. More details on Zachman here: http://www.mcs.csueastbay.edu/~lertaul/16_S039EL-S13.pdf (and they do a much better job than me).

the same "Enterprise Architectural Space Organizing

Table" on patternshare.org which includes a wide range of patterns

from some well known sources (Gang of Four, Fowler, POSA, etc)...

which may lend more impetus to this thread In addition to being a

simple way of classifying and organizing different architectural

perspectives by borrowing many of the concepts from Zachman, it

also appears to be useful way to classify and organize the

proliferating array of design patterns. I believe that some of

these patterns will become more relevant to the OpenEdge world as

we adopt more OO moving forward. But some of these won't be so

relevant especially the data-centric patterns because of the

inherent features of the ABL. It will be interesting testing these

and finding out which ones makes sense to use and which ones don't.

Phil

The first table was a little too much detail to figure out at first. The second table was clearer and made the first easier to understand. We've heard about patterns but still not sure what they are and what they do for you. We're new to all of this so we're still grappling with this whole area. Still a little confused as to what is an application architecture, what is an SOA, what are the differences. The tables helped to make this clearer some. Murray's also explanation helped a lot. More information about OO and patterns would help too.

The first table was a little too much detail to

figure out at first. The second table was clearer and

made the first easier to understand. We've heard

about patterns but still not sure what they are and

what they do for you. We're new to all of this so

we're still grappling with this whole area. Still a

little confused as to what is an application

architecture, what is an SOA, what are the

differences. The tables helped to make this clearer

some. Murray's also explanation helped a lot. More

information about OO and patterns would help too.

Hi Peter,

Yes, the first link was perhaps too much to dump on people without going through and explaining it or at least providing some guiding context. My intention was get people asking questions and/or providing their observations. I'll provide a little more to go on next time.

I still believe that this sort of material is useful to get a sense of the big picture. We have talked a lot about architecture in recent years and in particular the OpenEdge Reference Architecture (OERA) as a best practice to build applications using OpenEdge. But architecture as it pertains to integration and SOA is also now increasingly relevant and I believe that comparing and contrasting between these two different architectural perspectives - as well as others - is a useful exercise in itself.

On the question of patterns, they are like generic micro-solutions to common architectural, design, and implementation problems that can be adapted to specific instances. If you look at a current application you will probably see many repeating design and implementation approaches and these are considered to be patterns. There are growing number of these patterns I believe we should leverage what it is already out there wherever we can and only where necessary develop OpenEdge-specific patterns. The Java world and more recently the .NET world have been utilizing patterns for some time, and since we are building more object-oriented capabilities into the ABL, we have an opportunity to take advantage of them as well. This is new to almost everybody here and it will take some time to work through what we can take advantage and what we need to create ourselves. But I believe it will be worth the effort of investigating and discovering what works and what doesn't. This is a topic that I think we'll be discussing more and and in a lot more depth after the release of OpenEdge 10.1B.

Phil

The first table was a little too much detail to

figure out at first. The second table was clearer and

made the first easier to understand. We've heard

about patterns but still not sure what they are and

what they do for you. We're new to all of this so

we're still grappling with this whole area. Still a

little confused as to what is an application

architecture, what is an SOA, what are the

differences. The tables helped to make this clearer

some. Murray's also explanation helped a lot. More

information about OO and patterns would help too.

Hi Peter

We're currently working on a set of papers with respect to SOA, Business Drivers, Technical Drivers and how it relates to the OERA. These will hopefully be posted soon.

In the meantime you should hopefully find some useful materials with regards to application architecture, specifically the OERA here (http://www.psdn.com/library/kbcategory.jspa?categoryID=230). A good starting point may be this document (http://www.psdn.com/library/entry.jspa?externalID=1441&categoryID=54). If your really adventurous and want to see an actual implementation then please go and look at the AutoEdge work which has just been posted (http://www.psdn.com/library/kbcategory.jspa?categoryID=298).

But please stay tuned as we are constantly striving to post new material explaining all this stuff!!

Thanks

Mike

Your discussion about building a house is, of course, one of the prime analogies of the importance of modeling.

Relative to the question of understanding architecture, I suppose that my initial cool reaction to either of these charts is a combination of thinking that they are really about something other than architecture. The OERA diagram is about architecture. These seem to me more about how to do analysis and make sure that one covers all the bases.

This is, of course, a classic problem in software design, regardless of the specific architecture being planned, i.e., the person(s) who understand the business requirements are not the same as the person(s) who understand how to build software and the two don't communicate very well. Sometimes we have tried to address this by creating an analyst role on the software side, this being a person who is supposed to be better able to communicate with the business people, but who isn't a down in the trenches coder type. Sometimes this results in two interfaces of poor communication!

I suppose that charts like these are helpful, especially if one is insecure about one's analysis, by providing a sort of checklist so that one can be sure to have covered all the basis. I'm sure that is a good thing ... even if it may not be the way I typically work.

Here's the same "Enterprise Architectural Space Organizing Table" on patternshare.org which includes a wide range of patterns from some well known sources (Gang of Four, Fowler, POSA, etc)

Interesting ... and a little scary, how many of the boxes are blank and how concentrated the patterns are in a few boxes.

Interesting ... and a little scary, how many of the

boxes are blank and how concentrated the patterns are

in a few boxes.

An opportunity perhaps.

Murray, in reading your post I got this mental model of the idea of having a two dimensional classification scheme and extending it into a third dimension in order to break down each box in the original scheme according to another aspect. This is a very interesting notion, particularly if you think of there being multiple such additional dimensions which one considers at various times. I'm not quite sure what to do with this image, but I find it interesting. There have been a couple of slides from Exchange talks which sort of turned the OERA diagram on its side, which somewhat reflect this idea. Needs more thought.

It does, it was described to me (by a wiser man than myself) as an ocean with waves going over it it. The peaks and troughs often change as the project progress but what you typically find is that 2 or 3 boxes (or corners as he calls them) will dominate any particular project. Sometimes they are technically based but often they exist in personalities too.

The GoF (Gang of 4) book is a good place to start, as you mentioned.

BUT

without doubt, the most important thing about patterns and architecture frameworks is to realise that that "ARE NOT HARD" and you are already using them. Once you get over this "mental jump" - the value in them becomes much much more usable. I will say it took me 3 months to realise that "patterns" were stuff that I had been doing for years (e.g. Factory pattern). Now I don't even think about them - its just natural.

BTW - on the house side - go with the wife on the taps

We're currently working on a set of papers with

respect to SOA, Business Drivers, Technical Drivers

and how it relates to the OERA. These will hopefully

be posted soon.

In the meantime you should hopefully find some useful

materials with regards to application architecture,

specifically the OERA here

(http://www.psdn.com/library/kbcategory.jspa?categoryI

D=230). A good starting point may be this document

(http://www.psdn.com/library/entry.jspa?externalID=144

1&categoryID=54). If your really adventurous and

want to see an actual implementation then please go

and look at the AutoEdge work which has just been

posted

(http://www.psdn.com/library/kbcategory.jspa?categoryI

D=298).

But please stay tuned as we are constantly striving

to post new material explaining all this stuff!!

Thanks

Mike

Took a quick look at these. We need some time to go through it but it doesnt look too hard. I don't understand the UML though. Prefer to see some code. Still don't really get SOA or OO. We need more time to learn and need more info. But the info on this site seems a good resource.

And keep asking questions ... we are happy to help and sometimes even have the fun of a lively debate, which often does a lot to illuminate the issues. There is nothing intrinsically hard about any of it, just a lot of considerations which together make it seem complex. Once you start getting rules in place and breaking things down, I think you will find that the individual pieces of development are actually easier because they are so well encapsulated. You might want to consider picking up a UML book ... nothing hard there either.. or, for the cheap and quick version, check out the brief UML tutorial at http://www.sparxsystems.com/uml-tutorial.html

...

Took a quick look at these. We need some time to go

through it but it doesn't look too hard. I don't

understand the UML though. Prefer to see some code.

At the end of the day UML is simply a notation, and a means to an end, not the end itself. If it helps there are loads of books and web sites on the net that explain the basics. But I do undertand, anything new can sometimes appear complex. So that is why we also provided to code So if your happier starting that way, and then maybe working back to the UML models thats also great.

One thing that may help with this is something we've termed LiveDoc within AutoEdge. If you download and install AutoEdge you'll find some HTML based content known as LiveDoc (it can also be accessed by any running window of AutoEdge, including the HTML client). LiveDoc starts to tie together the code and the UML design work in hopefully an easy to digest form. It also walks you through the OERA and the components we've designed and built within AutoEdge.

Still don't really get SOA or OO. We need more time

to learn and need more info. But the info on this

site seems a good resource.

As I say, keep watching this space as we will be providing more SOA and OO based material.

HTH

Mike

There is nothing intrinsically hard about any of it,

Yes - I think this sums it up that best. Patterns, MDA, Architecture etc ... we have all been using it for years, both inside and outside IT. Many of these steps are just "formalising" the best way of doing things or giving guidance on how to do it. I use them to help jog the memory and ensure I don't forget things - its amazing how many things (e.g. non-functional requirements) get missing if you don't have a checklist. Its also amazing how many things "just happen" when you develop and support internally or "just happen" in one company but not another ...

I wouldn't be without these tools now that I have them - in the same way I wouldn't try and hammer in a nail without a hammer (or nail gun) - its tool but its very useful in the right context (of course - try to saw with a hammer - while possible - isn't fun and neither is developing / architecting large pieces of software your own - without tools ).

Muz