New App Dev Platforms for the Resourceful Enterprise
- By Alan Radding
The Big Idea
PLANNING TO DEVELOP
- Enterprise apps increasingly support the services approach to development. ERPs are no exception, featuring data schemas, object sets, APIs, sticky middleware and GUIs, among other tools.
- Some enterprises are using these industrialstrength ERP systems as development platforms for service-oriented architectures.
- New ERPs are much easer to work with, say systems integrators, but if you're using them as app dev platforms, you'll need to carry a heavy tool bag.
When Texas Instruments wanted to reduce the amount of custom coding
needed to continually refine its hodge-podge of enterprise apps
and middleware, it decided to lay a foundation for a service-oriented
architecture. What’s surprising is that TI turned to SAP and its
middleware NetWeaver as the dev platform.
TI is not alone. The big ERP players—SAP, PeopleSoft, JD Edwards, Siebel and others—have emerged as SOAapp dev platforms for many enterprises. Microsoft—with
its Axapta ERP system, soon to be re-branded as Dynamics AX—promises to do the
same in the Microsoft-Intel arena.
“All the ERP vendors are rebuilding their products as sets of loosely coupled objects
and components,” says Judith Hurwitz, president of Hurwitz and Associates, a
research and consulting firm. These extended ERPs enable developers to compose new
apps from loosely coupled components, Hurwitz says. Developers can also bring other
systems and apps into what used to be the classic ERP.
Industrial-strength middleware is what glues these newly reincarnated ERP systems
together. “They have long offered some middleware, mainly for themselves,” Hurwitz
says. “Now, they are providing middleware for all variety of applications. In SOA,
the middleware layer is critical.” The result is a platform combining data, processing,
dev tools, process modeling, SDKs, APIs and middleware, which, when taken together, look an awful lot like an app dev platform.
But ERP systems still have a way to go.
The agile angle
Software QA isn't at all inimical to agile concepts and methods. There is a sense in which software quality efforts, especially if they're imposed as top-down mandates, might strike many codejockeys as misguided—and inherently anti-agile—management initiatives.
Consider the idea of software quality-level agreements, which are a lot like service-level agreements. To the extent that a QLA insists upon a thorough adumbration of project requirements or presupposes the use of other waterfall-like methods, isn't there a danger that it will be incompatible with some agile disciplines?
This isn't to pick on QLAs, either: Isn't any software quality initiative that originates outside IT likely to be inimical to agile practices? Not necessarily, agile practitioners say. “If someone has some requirements and can suggest how to test them, they certainly should. That is not anti-agile,” says Ken Auer, a principal with custom software dev house Role Model Software.
Auer, an agile adherent, says most agile methods aren't at all reflexively opposed to requirements. "Agile is not against requirements. It merely rejects the idea that it is smart to try to figure out all the requirements up front without getting feedback from working—or somewhat working— software, based on customer responses."
There's another wrinkle. One best practice that's espoused by many agile enthusiasts is the idea of top-down management buy-in. Because some agile approaches to software dev are so counter to the expectations of executives and line-of-business customers, this is key. In orgs in which agile practitioners have already greased the skids, there's an excellent chance software QA initiatives such as QLAs can be designed to comport with the specific flavor (or flavors) of agile used in that enterprise. After all, some folks say, even agile and waterfall share points in common.
"When we look at agile dev and agile testing techniques, you still need a way of managing your assets and your results and correlating them back again," says Mark Eshelby, quality solutions product manager for testing-tools specialist Compuware. "So in the case of agile, which takes a test-first type of approach, you want to make sure that at the end of that project, all of the tests have been run appropriately. You want to know what the pass/fail is. You want to adapt to measure stuff like that."
And if reconciliation isn't possible, says Auer, agile teams can take a page from the suits. "Why not have a reverse QLA? Every time the business people change a requirement or come up with a new requirement that they hadn't previously identified or had identified incorrectly, there is a negative consequence. This seems to work in the waterfall process where change orders demand a lot of ceremony and, usually, some extra dollars."
Classic ERP systems combined comprehensive
business process logic and rules,
data and data processing, and workflows in
a massive, integrated and customized application.
In theory, they provided the
company with everything it needed to support
its core business functions, along with
embedded best practices.
In practice, it was a different story. “Historically, customers have modified
their ERP systems,” explains Jose Lazares,
Oracle’s senior director of product strategies.
“They might modify process steps
through configuration, extend the base
data model beyond the base objects, personalize
the UI, integrate with homegrown
and point solutions, and build out
The robustness of the emerging ERP
systems in terms of data schemas, object
sets, APIs, middleware and GUIs encourages
companies to consolidate their development
on an ERP, asserts Lazares. “If
the applications sit mainly within the ERP
system, it makes sense to use your existing
skill sets and just build on your ERP
system,” he says.
Not one-stop dev shop
The big IT consulting firms that do much
of the ERP implementation, integration
and customization work are buying into the
ERP-centric dev approach, but caution that
from a dev perspective, more than what the
ERP product alone provides is needed.
“We have made the ERP tools part of
our reference architecture,” says Robert
Hershey, senior VP for application services
at BearingPoint, an IT services firm.
BearingPoint assembles a toolset for its
Oracle ERP customers who must comply
with Basel II, the European Union financial
regulation. The toolset includes tools
for handling everything from the database
to ETL to reporting. It also provides integration
points and templates and relies on
a combination of high-level modeling and
“You cannot look at [ERP products] as
a one-stop development shop,” Hershey
explains. “You need the flexibility to do
what is right for the client.”
When Numeric Computer Systems, a
supply-chain software developer, started
working with ERP packages a decade ago,
it required painstaking point-to-point integration,
working through dozens if not hundreds
of proprietary APIs. In the process,
Numeric’s developers needed to navigate
through thousands of database tables, guided
only by cryptic names and labels.
The changes to ERP packages have greatly
improved the situation.
“When we tried
to integrate [our software] with the Oracle
eBusiness suite, we got into a detailed technical
discussion with Oracle,” says Robert
Hochberg, president of Numeric Computer Systems. “They fast-tracked us to their
integration group, who helped us evaluate
the different ways to do it.”
Oracle’s dev environment is based on
Project Fusion, the company’s vision for
next-gen enterprise technologies, apps
See “The Leap from Illusion to
Fusion,” in the November issue or on the Web.
New ways to change
The services-oriented approach is changing the way companies build apps. “The new thing today is service-enabled,” says Ori Inbar, VP of solution marketing for SAP Platform. “Instead of traditional deployment, systems are broken into reusable, functional modules.”
SAP offers an enterprise-services architecture based on widely accepted SOA standards. “It will give customers the ability to pick functionality and combine it in new ways to create a new business process or to support some change,” Inbar explains.
Rather than trying to build an app in Java or C++ or by using SAP’s business APIs, developers will use modeling tools. “This will make it much easier than in the past,” Inbar says.
Not so easy that any business manager can model a new app, however. Developers will still need to understand data structure and processing. “Programmers will always be needed, but there will be a shift of balance to people closer to the business,” Inbar says.
SAP programmers and technically oriented business analysts will model changes using visual tools instead of writing code. “BAPIs are still around, but now enterprise services take them a step further,” Inbar explains. Programmers will access the BAPIs as Web services, and the most commonly used BAPIs will be productized.
For support, SAP has organized an enterprise services community to help define enterprise services. These services will be included with what SAP calls its “business process platform.” Says Inbar: “The pre-built services will save companies a lot of effort. Basically, they get pre-integrated solutions using the same business objects and the same metadata that we use ourselves.”
Siebel, the CRM provider, pioneered the services approach, according to Anthony Lye, Siebel group VP. The company launched its Component Assembly tool specifically for building front-office apps on top of its CRM product. The tool provides a set of Siebel artifacts—interfaces, APIs, libraries—that customers can use to build apps based on Siebel components.
The resulting apps are SOA enabled, built as J2EE or .NET services. Developers can assemble composite apps using Siebel’s objects and those from other vendors. Apps can be built as standard Web services or in C++.
Siebel 7 comes with a full set of tools and a workbench to allow developers to modify processes and link to the core CRM product via Web services and C++. “There could be some programming involved,” Lye says. “It’s the same tools my group uses when we build the application.” The Siebel app and services sit above a middleware layer such as NetWeaver and can work with whatever middleware or app server the org wants to use. Testing, however, will be required to ensure it works as expected if Siebel has not certified it.
The goal is to protect customer investments
by enabling them to use functionality
from PeopleSoft, JD Edwards
and Oracle product lines. Project Fusion
uses Oracle Fusion Middleware to give
orgs access to Java, composite apps, master
data consolidation, grid computing
and other powerful technologies.
Numeric discovered that Oracle’s Fusion
middleware and Business Process
Execution Language tools, which enable
orgs to orchestrate services and business
processes in a standardized way, offered
the easiest solution. “For most of our applications,
it would have been pretty
simple any way we did it,” explains
Hochberg. “We just had to map this field
to that field. However, one of our touch
points is very complex. It starts with
querying one Oracle file, but then we
start linking to lots of other files and doing
various processing. BPELmakes this
The fear of blowing away the latest integration
with each ERP upgrade is also
a worry of the past. “We have a BPEL
adapter for our application, and Oracle
has a BPEL adapter for the ERP application,”
Hochberg says. “Now, when
something changes, it only affects the
adapter, not the software.”
Dynamically one step above
WIKAInstrument, a manufacturer that
specializes in pressure and temperature
products, opted for Microsoft’s Axapta
to replace an aging ERP system built on
a Progress database. The company liked
Axapta’s “lean” manufacturing add-on,
according to Darren Hogg, CIO.
With facilities spread around the
world, “We do a lot of customization.
With the previous product, there were
a lot of services packs, which really impacted
our customization,” Hogg says.
The situation got so bad the company
decided it simply wasn’t worth the effort
to upgrade. That meant giving up whatever
improvements the service packs
Axapta eliminates that problem.
Through its object-oriented architecture, “our changes sit at a level above the
ERP code,” Hogg says, “and it is a very
dynamic system; we can make a change
at one level, and it tells us how it will affect
the code above it.”
This approach allows WIKAto standardize
on a core set of ERP functions.
The manufacturer built a library of
reusable Axapta modules, which enables
each global facility to pick the functions
it wants to adopt. “It saves us from having
to do the same programming over
again,” Hogg says.
WIKA’s team can add new functions
so easily and quickly with Axapta’s Morphx
tool that they no longer bother with
commercial add-ons. “It’s hard to tell if
the add-on is exactly what you need and
whether it is at the same service-pack
level as you,” Hogg explains.
Axapta ERP includes apps that business
managers can use to manage finances, customer relationships, supply
chains and other business processes. Because
it integrates with other Microsoft
products—SQL Server, BizTalk Server,
Exchange, Office and Windows—employees
can work with the tools they are
familiar with, lowering training costs.
“Axapta was conceived to be completely
modifiable by the customer,” says
Michael Merfeld, solution director for
the Microsoft business solutions practice
at Avanade, a consulting firm jointly
owned by Microsoft and Accenture.
“It is meant to be very flexible.”
Users can standardize on a standard UI
or customize their work environments using
Morphx, which enables them to design
workflows, screens and menus.
The real power of Axapta lies in its
object-oriented design, Merfeld says. “IT can take advantage of inheritance
as a way to change objects.” For example,
if the organization needs to change
the size of the field to accommodate a
larger production number, it changes
only that property in the production
object, and inheritance ensures the
change happens wherever that object
makes an association.
“You can even do it in the object library,
and it is no harder than changing
a property in a Word document,” Merfeld
ERPs are definitely getting easier to customize
and integrate. With ERPs’ abilities
to handle both services and objects, standardized
interfaces, robust middleware
and metadata facilities such as BPEL, programmers
and even savvy business analysts
can do more with these systems—more
easily—than ever. Still, developers need
more than what the ERP system alone
provides—they may find themselves diving
deep into Java or C++.
ILLUSTRATION BY JIM FRAZIER