When I get around to buying a new car, I know what is important to me. Being 6 feet 4 inches tall the first criteria is whether or not I can sit comfortably and see myself driving many miles, and then small things become important, like whether I can see the lights at an intersection. The comfort criteria is independent of the car and must be applied to all cars that I try, although I do like the image of relatively fast cars. When you look at what I drive, it might surprise you, I have a Ford Focus SVT which is good for 140 mph and 0-60 in about 6-7 seconds I am told. Many people have asked why I do not drive a SUV or similar and the reason in many cases for me is that they typically have less room for a driver of my proportions than my Focus.
When I bought my car, there was a lot I already knew. Having driven many cars, I knew where the steering wheel, radio, rearview mirror, etc. were and I knew that I could drive the car without a specific driving course, although to push the limit and understand how it would go 140 mph on a sweeping right hander would probably require a day at some race track. My wife on the other hand has to transport kids to the school and to soccer practice so her vehicle of choice is a minivan.
Now that I have shared with you some of the reasons how my family chooses cars, you may be wondering how this relates to SOA. Well, last week in a meeting with customers and prospects alike, I was getting questioned on selection criteria for ESBs and SOA infrastructure technologies. And in nearly every conversation, the same criteria was clear - how many messages per second, how much memory, etc. etc., and only a few really came up with a statement such as "We are facing challenge X and would like to solve it?" This is the most important question because just like my car challenge of "sitting comfortably for long periods of time" outweighs the need to do 140 mph (which I have yet to do), if I bought a car that does over 150mph, it would probably be gone by now as it might not meet my primary needs. And lets face it, how fast do any of us really need to drive? Even the cheapest car on the market will do 80mph all day.
Using standards such as Web-Services, JMS, etc. also means that developers can apply the same disciplines to one technology as another - in much the same way that most drivers can switch cars. If it did not, Hertz and other companies would not be in business. Which brings me to the second theme of questions and comments I was getting, "What do my developers have to learn to be successful?" They have to learn to transition from one environment to another but still be able to apply the same core software engineering practices. For instance, you would not write all your business logic in one Java class so don't do the same in one ESB process. In CORBA you would not make every object accessible, so why do you try to make every Java object a web-service?
SOA What? Buy the technology that makes sense for you and your business, e.g. if you are a distributed manufacturing organization build/buy a SOA that can be deployed and managed in a distributed manner. If you are dealing in high volume transactions or events, you will, like a racing driver, need to look into performance. Once you have chosen your SOA technology, remember to still stop at red lights, and not to redline the engine at every gearshift. The speed limits may have increased, and you can break them later, but they still exist. And just like I would get special tuition to drive safely at 140 mph, remember to call on the experts of your SOA to drive at the limits.
View all posts from David Millman 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.