OpenEdge and the Not-Quite-Accidental Architecture

We’ve been talking for a long time now about the OpenEdge Reference Architecture (see a host of definitional and example materials at www.psdn.com under the new Service Oriented Business Application Expertise Center). The OERA is the diagram with the layers from Presentation and Enterprise at the top down through Business Components and Data Access to Data Sources at the bottom. A lot of people at Exchange and elsewhere where we’ve had a chance to connect in person find the discussion stimulating but intimidating. “Thanks for the presentation. I see now how complicated this architecture stuff is now.” Hmmm. That wasn’t exactly the message we were trying to convey. It’s understandable how the layers make it seem like it is going to be harder to implement a well-architected service-oriented application, but the intention is just the opposite: to help you make it easier, not harder, to get your application to where it needs to be for all that loosely-coupled agility that you know you need.

So how does it wind up being easier? I have a couple of simple principles I have been trying to get across in more recent materials:

1. Let each component of your application (a procedure or a class, whatever) do just one job and one type of job.

How many procedures in your application are there that do a whole application operation from soup to nuts, as it were, from user interface to business logic to database transactions? If you can break those up into pieces that do one type of job – user interface, business rules, mapping to database tables, or database transaction – then you’re well on your way to having components you can reuse when you need them, rather than copying and pasting old code into new places and then changing it to suit new circumstances.

2. Do each job once and only once.

And how does this wind up making your development job easier?
Well, how many places are there in your application where the code… – fill in the blank here with your own list of completions to the question: calculates a price, validates the correctness of an order, checks a user ID for access to an application module, joins six related tables in the database, whatever. If you can factor out redundant or similar code for any of these kinds of activities, you’ve certainly simplified your maintenance and testing job, and probably made it simpler to do a related version of the same job the next time you have to.

And where does the not-quite-accidental part of the architecture come in? One of the key messages we could do a better job of communicating is that you don’t have to tackle the whole job at once: the OERA represents a set of guidelines and ideal goals, not an absolute all-or-nothing necessity. So if you think in terms of making your application structure a little bit better each time you change it rather than a little bit worse, then you’re headed in the right direction. And you’ll see that starting in on principle #1 is really a prerequisite to principle #2. If you start breaking out chunks of code based on what one job they do, then it will be much easier to reuse them. Take all those price calculations; factor out the common code and parameterize the variations; create a straightforward API that lets another part of the app call in with needed inputs and get back needed outputs; and eliminate assumptions in the code about the nature of the caller; and voila! – pretty soon you’ve got a Business Component with a Service Interface (that’s the common API part) on the front of it. At that point OpenEdge makes it easy to call that Business Component through the Service Interface from all over, including from other applications and new user interfaces.

Find all the places where your code checks a user ID against permissions on an application module; move them into a single procedure that does that job and call it wherever it’s needed; and voila! – you’ve got the beginnings of Common Infrastructure. So you don’t need to solve the whole problem at once. Just head in a direction that makes it easier for you to identify what all the bits and pieces do, and sooner or later you’ll have an application code that has got a real architecture to it. And think how much easier that will make your life in a world of new UIs and Web services and all the rest of what you have to deal with. Follow the right principles and – not quite accidentally, but pretty close – your application will start to have an architecture after all.