LAMP and SOA
This entry was posted on 6/23/2006 1:47 PM and is filed under Software.
Recently there's
been more and more activities out there regarding why and how to use the LAMP stack
connected to enterprise business applications. As recently I read two articles
(this one and this one) concerning how SAP and its competitors approach this
topic,
I started thinking about whether today's state of the art architecture, namely
SOA or more precisely how SAP applies it, enterprise SOA is a competitor of LAMP and especially scripting languages and frameworks (Perl,
PHP, Python, Ruby & Rails, Groovy & Grails etc.) or they are rather
complementary. My conclusion is that both approaches can be valid but the latter
one seems to be more viable in the long run.
Why am I telling
that?
As it can be seen
from the articles mentioned, SAP is supporting LAMP much less than others. And
it has a good reason. While for example PHP's history is full of being being
used for implementing (mostly small, partly large) websites with some business
logic but almost no so-called backend functionality, ERP and other enterprise
applications of SAP are run mostly by huge or at least big enough
companies.
If you consider old
versions of ERP systems or smaller customers that don't want to invest in the
Java stack of Netweaver, the only two ways of extensibility are changing ABAP
code or use any language that has RFC connector and call BAPIs or whatever.
Having this situation, in most of the cases it's not only feasible but maybe one
of the best options is to use Scripting in a Box, choose your favorite scripting
language and go ahead.
However, if you have
to implement something for a bigger company and/or on top of a newer version of
MySAP that includes Java stack, probably it's better to utilize the capabilities
that SAP provides. I'm telling this because of two main reasons: one is that
Java as a platform is in my opinion much more designed to be the base for
applications having a relatively high architectural complexity; and two is that
SAP delivers various modeling and development tools and runtime environments
(for example Enterprise Portal, Composite Application Framework including Guided
Procedures, Visual Composer) that make it easier and more cost-efficient to
produce custom applications on top of the MySAP suite (or later on, the
Enterprise Service Repository).
Last but not least,
don't misunderstand me: as a skilled programmer I like very much scripting
languages, mostly Perl, sometimes I don't even understand why operating
systems have other user interface than bash or ksh 
, but the trend, that
probably none of us can turn back, is to empower more and more people with less
and less technology skills to implement or adjust business processes implemented
with IT systems quicker and easier.
However, I don't
fear that we as programmers will lose our jobs in the next 300 years or so
