Friday, January 18, 2008

Magic eDeveloper V10 and ROI for Start-Up Businesses

The economy has been showing signs of weakness. Despite this, thousands of entrepreneurs will be launching new businesses, even in the midst of a new economy. How does that affect software development? Building the software systems for these new businesses is a critical process and one that must complete in the least possible amount of time. During slow economic times Return on Investment is on the mind of every entrepreneur who has to sign off on a development budget to get the new business systems in place that will deliver their unique competitive advantage. So in today’s business climate, the emphasis is on rapid return on investment. The break-even point needs to be achieved at the earliest possible moment. Every cost has to be analyzed against the expected returns to arrive at estimated break even dates. So here’s my claim: “You can achieve ROI in your application development process faster and with greater assurance when using eDeveloper V10.”

Application development tends to occur in phases. For our purposes, let’s consider these four phases: Design, Build, Test and Deploy. In the harried environment of a new startup business, you need to have all four of these occurring almost simultaneously, but traditional computer programming tools do not allow this. All four of these phases require an investment of time, but if you can execute some of the phases in parallel, then you can get to the final destination faster. So testing isn’t something that happens at the end of a software process, it is an iterative process that occurs throughout the project. For this reason, it may be more useful to think of Design, Build, Test, Maintain not as phases, but rather as layers of the development task. The design layer tends to be front-loaded in the project, but some design occurs while maintaining the program. The test layer tends to be back-loaded towards the end of a project, but using sound iterative design principles, testing definitely occurs throughout the life of the project.Time is money is perhaps a cliché but critical when discussing the ROI of business software development projects for new businesses.

Application Development ROI calculations must put the emphasis on the investment that goes into dollars paid to the developers on the project; i.e. how many developers will it take and for how long? The sooner the project comes to a successful end, the faster the ROI for the project, and the sooner the new business can deploy their new systems and reap the benefits.

The time saved - hence the ROI - using Magic eDeveloper V10 is significant: typically from 4 to 6 times faster than that of other development technologies.
The table below is based on extensive market research and compares each of the four phases (layers) of the application development lifecycle for 3GLs (Third Generation Languages), 4GLs (Fourth Generation Languages) and Magic eDeveloper. If X, Y, Z, and W represent the time spent on an average 3GL application for each of the application development phases, research shows that generally 4GLs cut the time in half. With Magic eDeveloper even better time- savings are achieved. The productivity gains shown below are conservative calculations by Magic Software based on interviews with eDeveloper programmers, many of whom are quoted later.

In order to achieve rapid ROI, each phase of the lifecycle must not only be completed quickly, but must also have the highest reliability to ensure the fastest payback for the investment being made.
In going through the analysis of each of the application development lifecycle phases in future blog entries, I will detail additional aspects of Magic eDeveloper that result in further ROI increases.

Magic eDeveloper’s progressive development paradigm allows prototype applications to be quickly and easily created. The eDeveloper paradigm is often used to convince venture capitalists and other investors that achievement of a new start-up businesses goals for new business systems is in fact achievable. Without eDeveloper, some businesses might not even “get off the ground.” In addition, the ability to support applications over time despite changing business models, platforms, and standards is inherent in the Magic eDeveloper development technology.

Rapid ROI remains a key critical measure for every new business and is often the difference between success and failure. I’ll comment more on the savings possible during each phase of the application development cycle in later posts.

Thursday, January 17, 2008

Top Ten Ways To Gain Approval of Your eDeveloper Upgrade

Getting the boss's approval to upgrade important software can be a challenge, particularly when budgets are tight. Here are a few tips on how to get approval to upgrade eDeveloper V10:

  • PREPARE. Go in armed with all the necessary materials to make a good case for your upgrade. Download the “Ten Reasons” brochure and visit the series of blog entries on reasons to upgrade in Glenn Johnson’s eDeveloper V10 blog.

  • LEARN. Attend the Magic University course “Migration to eDeveloper V10” so that you can speak with authority on the capabilities of eDeveloper V10. Download the FREE EVALUATION SOFTWARE and consult the "What's New in eDeveloper V10" and other documentation.

  • RELATE. Show how specific problems or issues you've recently encountered can be overcome by one of the improvements in eDeveloper V10. Ask for a Magic representative to setup a live web presentation on your upgrade to eDeveloper V10. Invite your opeers and your boss to participate in this information gathering session.

  • SHARE. Point others in your organization towards the new learning resources in eDeveloper V10: the “Mastering eDeveloper” book and the 22 online demonstrations.

  • SAVE. Point out the ROI benefits of migrating to eDeveloper now, before you release a new version of your software based on your current version. Cost savings, productivity enhancements, application improvements, user interface benefits, and much more, are all available immediately, but only if you make the leap to eDeveloper V10. A delayed start to active development using eDeveloper V10 equates to a very real loss of benefits to your company.

  • TEAM. Review the benefits of eDeveloper V10 with other members of your development team. Gain an understanding of how the improvements can enhance efforts across your development team.

  • CONSULT. Magic Professional Services can help to provide you with a migration readiness assessment. This formal consulting process will help you to plan for all aspects of your migration to eDeveloper V10.

  • LAUNCH. Ask for a commitment on a specific launch date for your team’s use of eDeveloper. Come in armed with a launch plan.

  • MEET. Set a specific meeting in which you can present your upgrade request to senior management. Make it clear to everyone that this is an important and needed decision.

  • DECIDE. Give a deadline to make a decision. Present the information and ask for an answer within a specified time frame. Reiterate that procrastination has real expenses and costs associated with it as well as lost business opportunities.
  • Friday, January 04, 2008

    Developing RFID Applications with eDeveloper V10

    Last month, I attended the Active RFID Summit held in Dallas, Texas. In addition to enjoying a chance to sample some excellent Tex-Mex dishes, I really appreciated the chance to compare notes with colleagues on the state of the art application of RFID, especially active RFID. Regardless of whether you are developing proprietary applications, vertical applications for a specific industry or horizontal applications that serve cross-industry needs, RFID is putting a strain on IT resources. Active RFID represents a major paradigm shift in data acquisition and generation creating an onslaught of data that current applications are generally not prepared to handle.

    Stephen Moody, an RFID Program Coordinator for the Combat Feeding Program of the US Army's Natick Soldier Research Development, presented a fascinating case study entitled: "DoD Active RFID Applications for Supply Chain Security and Shelf Life Management." It is easy to underestimate RFID as something akin to a glorified barcode or a "traveling database". But many active RFID tags are far more sophisticated in that they incorporate environmental sensors. The US Army sends tons of rations to the troops in Iraq and elsewhere. These shipments are made in ships holding thousands of standardized shipping containers. How can the US Army be sure the shipments have not been tampered with or exposed to unacceptable environmental conditions? The answer is active RFID tags with sophisticated sensors for a number of environmental events: temperature, radiation, light, chemical agents, biological agents, shock, door sensors, etc. If somebody is doing something to a shipment of food, or if it just gets too hot for too long, the US Army knows when it happened and where it happened. This is simply one of scores of applications for active RFID in an organization like the US Army. But what does one do with all that data? According to Moody, "the greatest barrier to the successful implementation and adoption of RFID is integration to legacy systems."

    One of the other challenges for RFID is the current lack of standards. In some ways this is unavoidable: RFID is not a specific product, technology or protocol. RFID is a family of technologies that incorporate radio frequency and are used to identify "stuff." As Sue Hutchinson, the Director of Industry Adoption for EPCglobal US put it, RFID provides the answer to the question "where's my stuff?" But the type of RFID may involve passive RFID, where the tag has no power source and is a write-once technology, to active RFID, including ultra wide-band (UWB), all the way to GPS and beyond. With such a diversity of technologies, standards become even more important. Lacking these standards, however, flexible development and integration tools become even more important.

    Consider the food safety example above, somewhere in an ERP system the information resides for the supplier name, items ordered, supply date, carrier and so forth. Does this information get integrated to the data on the RFID tag? What happens if food from one supplier is more prone to spoilage or to lose palatability under prolonged high temperatures? How can the US Army, or any organization for that matter, take full advantage of RFID applications if key information sits locked in a silo such as an ERP or supply chain system?

    Information integration is the key. But how does one best handle RFID integration with an ERP or other existing application? To answer that, we first need to consider the RFID system being used. RFID systems involve tags (some with built in sensors), programmers, readers, networks and so on. But most do not include middleware. And the hooks provided are inconsistent. Text files, XML, .NET objects, java objects and Web Services are provided inconsistently. For an organization to be prepared to integrate the data from a reader, they can benefit from a middleware solution like iBOLT that provides the ability to consume any of these data types and orchestrate them within an overall business process. Or they can create interfaces from directly within an eDeveloper application. Even when dedicated applications are written to take advantage of RFID data, middleware and business process management software is still needed to facilitate integration to legacy systems. Ideally, these middleware systems are service-oriented including event driven capabilities, discoverable web services and more.

    Unfortunately, too many RFID early adopters are resorting to hefty J2EE or.Net based programming projects rather than utilizing a development tool like eDeveloper V10 or a simplified visually-oriented business process design tools like iBOLT. As the world begins to find more and more uses for RFID, it will be useful for serious organizations to incorporate eDeveloper and iBOLT for integration to RFID data, whether it comes in raw text or XML format or is served up by a Web Service or programming object like .NET or XML.

    With RFID, the emergence of integration file standards is far from certain. The Auto ID Center has proposed an XML format known as PML as a standard. You can read about it on the XML CoverPages hosted by OASIS. But the adoption of the standard is far from ubiquitous, especially in the Active RFID world which tends to look at organizations like EPCglobal with at least some degree of suspicion.

    The good news for eDeveloper programmers is that since PML is just a flavor of XML, you can access RFID data with standard eDeveloper XML tools. To see what you’re avoiding, take a look at the PM example below. For more information on RFID and iBOLT, you can access Magic Software’s RFID related webinars.

    Using PML in eDeveloper V10
    eDeveloper V10 includes a new capability called XML Integration. This approach makes PML’s use within eDeveloper much easier. In fact, you can now develop applications using eDeveloper with no database at all and simply use XML files, including PML for RFID and other Auto ID related applications.

    When using a PML data source containing RFID data, you can create eDeveloper tasks (batch and online) that use the PML files as their view (main files and linked files). You can define an PML data source in the Data repository (remember PML is XML) and define a task to manipulate and handle the PML. You can check that the XML task is compatible with the XML schema by using the XMLValidate and XMLValidationError functions. Namespaces are automatically handled by eDeveloper.

    There are two XML development methodologies to choose from. You can develop applications using XML in the data repository or you can develop using XML with BLOBs. If you use both methods, then the BLOB takes precedence.

    With eDeveloper V10, a task that uses XML (such as PML) will first open the entire XML file (if it is not already open) and then populate the tables. It then executes the defined task, whether that be query, insert, update or delete. Finally, when closing the task, if the data has changed, then eDeveloper V10 writes the XML BLOB or file back over the original XML source.

    eDeveloper V10's XML Integration feature provides two functions that allow you to verify that the XML is compatible with the XML schema.

    The functions are XMLValidate, which validates an XML document against its schema; and XMLValidationError, a function that returns the errors of the last XMLValidate. This will help you to determine whether your PML file is valid based on the PML schema, which of course is found in the .xsd file.

    With eDeveloper V10, you can use the Get Definition function to discover the properties of a PML file that contains RFID data and map them to an eDeveloper table. Like all XML files, PML files are described by .xsd metadata that contains the XML schema definition. During a Get Definition, if an element’s/attribute’s type is defined using a SimpleType or as a reference to a Global element, it will be converted to the appropriate Primitive xsd data type from which it is derived.

    Primitive xsd data types are mapped to corresponding eDeveloper attributes. Once this occurs, the field attributes can be changed without restriction. A default picture (most of the time you can think of this as length) will be assigned (as specified in the table). When the type is based on a SimpleType, which defines length, the picture will be updated with the length specified for the SimpleType.

    What About Other RFID Data Integration Types

    To be sure, RFID vendors are not uniform or universal in their support of RFID data via PML or XML. Fortunately, eDeveloper has built in functions for the other common methodologies as well. Some vendors supply RFID Web Services, which means you can use the eDeveloper V10 Web Services wizard. That’s even easier than dealing directly with PML or other forms of XML.

    Occasionally, programming objects such as java objects or COM objects are provided, in which case eDeveloper can call and pass information to these objects. Keep in mind that Active RFID enables two-way data communication and write-many read-many (WMRM) storage with an RFID tag, whereas, generally speaking passive RFID is a write-once read many (WORM) technology. That means your eDeveloper applications need Active RFID if they are going to do any of the more sophisticated RFID applications.

    Ways to Apply RFID Technology in eDeveloper Applications
    Going back to Sue Hutchinson’s comment, RFID helps to answer the question: “where’s my stuff?” One way to determine this is to sense the immediate presence of an FID tag next to a reader. This approach works well, with say, tagged parts that are passing along an assembly line. The parts are always within range of the reader. Another example of good stationary reader approaches might be warehouse doors. Some work has even been done to create “smart shelves” that sense the RFID tag of products as they are pulled on or off the shelf. For these close proximity applications, passive RFID may be satisfactory.
    But the real world does not always have these convenient thresholds.

    One of the technologies developing around RFID are Real-Time Locating Systems (RLTS). These systems measure the wave properties of an RFID signal to determine the location of an RFID tag. The readers are generally placed in a grid and then tuned to a room or outdoor location. Since waves travel inconsistently through and around walls, etc., bandwidth is a consideration with RLTS. In cramped spaces, UWB is often preferred and it may offer energy saving advantages as well. Battery life in an RFID tag is another important consideration. Beacons that emit constant signals use more energy and have shorter battery life than systems that simply “chirp” at an established interval.

    Software algorithms that calculate the location of a tag by comparing signal strengths on a grid of sensors are quite sophisticated. But they aren’t always accurate. Practical field applications show that errant readings are fairly common. When possible, a location should be calculated based on the average of several readings and not just a single reading. This approach leads to a great deal of accuracy.

    RLTS can be used in applications such as worker safety systems. Companies like BP use active RFID in their employee badges so that if disaster strikes at a refinery or other hazardous work location, systems can be used to pinpoint the locations of workers and visitors. Needless to say, the RFID readers in these systems have to be “hardened” to withstand violent environmental conditions such as fire and explosion.

    Another common use of RLTS is in asset management software systems. These often take on specialized use in various industries. Nurses need to know which room an IV cart or other mobile medical equipment was left in. Newspapers need to know where the paper stock rolls are in their automated factory. Truckyard operators need to know which spot particular trailers are located in, etc.

    Glorified barcodes? Perhaps. But when was the last time a barcode could tell you whether the product it tagged has been kept at safe temperatures or automatically report its location? Sure we know we scanned it into inventory six months ago, but don’t ask us to actually find it in the store or warehouse.