Johannesburg, 04 May 2006
Service-oriented architecture (SOA) represents a significant opportunity for software developers in South Africa, says Rick Parry, MD of Progress Software South Africa.
South Africa has given the software world a great deal. Many observers have come to admire their capability, their tenacity, their sheer skill. Applications developed in this country are as good as or better than those in many other countries.
There are a number of factors behind this. One is South Africa`s historical isolation; another is the sheer geographic distance from countries in the First World. As a consequence, developers built inherent resilience into their applications, and South African applications are all but bulletproof.
One measure of this for us at Progress Software has been the number of calls from South African end-users to our help-desk - we simply take fewer calls from users here.
Other characteristics of South African applications, in our experience:
* They have been used for a long time - end-user clients accordingly enjoy significant return on investment. Customers are loath to spend more money on applications which have been amortised and which are working just fine.
* Many of the applications have been deployed in client/server mode, which lends itself to their reuse.
* They have been written by skilled programmers, drawn from a relatively limited pool of resources.
One of the challenges for South African developers is extending the availability of their applications to other developers and other companies.
This is where SOA comes in. Deployed against an enterprise service bus (ESB), it offers a brilliant opportunity for local developers to reuse their applications without rewriting and recompiling their code.
The architecture is relatively simple:
* The ESB provides a standards-based backbone to which a number of applications can be attached. Importantly, here we are not referring to full-blown applications, but components, or functions contained in the applications. These can be extracted and presented to the ESB as a Web service. In terms of standards, it is vital here that the ESB conforms to JMS (Java Messaging Service) 1.1 as this is light on resource usage, is highly secure, and easy to plug into.
* Of great importance to note is that the ESB, while it may have had its roots in message queuing (MQ), has evolved beyond other MQ products to become a solid, dependable enterprise backbone. It still guarantees once-only delivery of messages, but it also provides security, integrity and a message sorting capability. Paradoxically, the very rigidity of an ESB gives developers the flexibility to design any application suite and adapt to changing business processes. Using an MQ product to achieve the same outcome would require a "hardwired" approach, which is inherently inflexible. Indeed, it is fair to say that SOA cannot exist without an ESB approach.
* Relatively low-level code supporting dedicated business processes could then be plugged into the ESB and exposed as Web services. This is as opposed to entire business objects. This approach supports reuse of code, and capitalising on existing business process which can then be incorporated into a broader set of processes. Of importance is that this approach supports both Progress and third-party code - ideally newish applications written in the last five years.
The productivity improvements adopting such an approach are dramatic, to say the least: developers should expect an efficiency of anything up between 200% and 300% due to reuse.
This approach helps remove IT as an inhibitor to change and growth, a key factor in developers` thinking.
This has the potential to change the way in which developers plan and architect their applications; developers from now will ask: "How do I capitalise on what I have, rather than write from scratch?"
This is no silver bullet, I must caution. There has never been a sinecure for application development; no one-size-fits-all miracle tool that takes away the drudge and the slog of this most demanding of tasks. For it to succeed, there has to be a significant campaign of awareness and education among developers; and secondly, developers need to embrace new technologies, such as those embodied in our upcoming OpenEdge 10.1 development environment.
For developers and independent software vendors alive to the opportunity, this approach offers spectacular advantages.
Share