New App Dev Platforms for the Resourceful Enterprise -- ADTmag

In-Depth

New App Dev Platforms for the Resourceful Enterprise

By Alan Radding
March 1, 2006

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."

—Stephen Swoyer

History, rewritten
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 new functionality.”

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 hardcore programming.

“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 and services.

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.”

SOA-enabled apps

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.

—Alan Radding

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 much easier.”

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 provided.

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 says.

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++.

On ADTmag.com