Deliver superior customer experiences with an AI-driven platform for creating and deploying cognitive chatbots
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
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.
View all posts from John Sadd on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.