Newsletters- Winter 2005

Finding the Cutting Edge
by John W. Stout

Welcome to the Winter 2005 edition of the Stout Systems newsletter. Our long time readers will notice our newsletter's new title and look. One thing that hasn't changed is our commitment to cutting edge content.

When the tech sector slumped in 2001, a lot of wild and crazy Internet companies went under. Many genuinely innovative technologies were gobbled up by larger companies with a corporate - read non-entrepreneurial and slow to innovate - approach to development. Add to that the corporate mergers that have take place in the past few years - Oracle buying PeopleSoft, Symantec taking over Veritas - in the name of corporate Darwinism.

Is there still a cutting edge? Yes! It's still cool to be in the industry!

Innovation abounds in companies, individuals and open-source projects. And we promise to bring news of it to you each and every quarter. Our focus is not just on the theoretical, but on real world application so that you can quickly understand how the tools our writers espouse can be used in your solutions.

This newsletter now reaches thousands of readers in the U.S. and abroad, and we value your feedback. One response we've made to you is in our revamped Web site, making it easier to use. When you visit us at our new URL www.StoutSystems.com you'll find a whole new look and feel. The key content is still there. For those of you who are employers, you can find information on candidates for hire. If you are looking for a job in the high tech business, you'll find a new format for job listings.

Before closing, I want to publicly express my appreciation to our customers. 2004 was the best year ever for Stout Systems, as we shattered all previous sales and production records. It proves once again that with good working relationships success is always possible.

Here's to a prosperous 2005 for all!

John W. Stout is the founder and president of Stout Systems. He has twenty-five years experience in the software industry. He is also sought after as a technology speaker, presenting sessions at developer conferences and user groups. E-mail .

-back to top-

---

Web Services
by Bill Heitzeg

In the past few years, Web services have gained incredible momentum and I find myself working with clients to help them use Web services effectively.

A Web Service can mean more than one thing, but these days, when someone talks about a Web Service, they are most likely talking about a software system, identified by a URI (Universal Resource Identifier), which communicates using SOAP (Simple Object Access Protocol). In addition, we can also be reasonably sure that they are talking about a service which describes itself using WSDL (Web Service description Language).

When we combine SOAP and WSDL we have a service which communicates and exposes itself in a standard way. Since both SOAP and WSDL are based on XML, we also end up with a service that is platform- and language-independent.

A system like this has many parallels, including the two most popular, CORBA and DCOM. The biggest differentiator between these technologies and Web services is that Web services are not based on any proprietary technology. Because of this, Web services have gained a much broader acceptance in a short period of time.

One of the really nice things about Web services is that the standards define communication between parties without defining the underlying implementation. This means that implementers are free to choose the underlying language and platform. This allows for interoperability between two disparate systems without having to rewrite significant portions of one or both systems.

For in-house projects, the interoperability of Web services can be a lifesaver. I recently worked with a customer who wanted to reuse some Java methods in a .Net application. The Java code had been around for a while, running as a server on a Solaris machine. The customer was extremely reluctant to rewrite or rework the Java application. The goal was to be able to call a couple of methods from a C# application while leaving the Java code intact. Using the Open Source tool Apache Axis, we exposed the needed Java methods as a Web service. Then, using Visual Studio .Net, we imported the published WSDL. This allowed us to make native C# calls into the Java service without rewriting a single line of Java code.

The same standards-based interoperability that Web services bring to in-house projects can also greatly enhance publicly exposed software systems. It’s no surprise that industries that already do this in a proprietary way are turning to Web services to reduce confusion and cost. In the manufacturing industry, Web services are being used as the next generation of EDI (Electronic Data Interchange). With the help of electronic business XML (ebXML), manufacturers are building standard business-to-business systems using Web services. In the travel industry, Web services are replacing proprietary communications standards. For example, the Open Travel Alliance is using Web services to create a standard way for suppliers and consumers of travel products to communicate.

Software reuse is one of the big promises of Web services. A brief search of the web reveals literally thousands of publicly available web services. A programmer, using the exposed WSDL of these services, can quickly hook into all kinds of services such as weather, government documents, and shipping systems. Many prominent web based companies have started moving into this market place. Google and Paypal are exposing parts of their technologies as Web services using the SOAP and WSDL standards. Microsoft is currently making Mappoint features available, including the map images themselves, via a Web Service. Amazon is also making critical parts of their product available as Web services. I expect that in the near future it will become common for organizations to reuse one or more Web services as part of their product offerings. This will reduce their in-house code investment, their time to market, and their overall maintenance costs.

As a programmer, I can’t help but feel that success of software technology is directly proportional to the availability of tools for that technology. If I’m right, then Web services will continue to be a great success. There are good and excellent Web services tools available for just about every platform and language. Microsoft, IBM, and BEA all integrate client and server side web service tools into their IDEs. SUN and Apache have made significant investments in Web Service APIs. Beyond that, new markets have opened up for Web Service monitoring, inspection, and testing tools.

The World Wide Web Consortium (W3C) is the keeper and extender of the SOAP and WSDL standards. The W3C is a non-profit standards body responsible for many Internet standards including HTML and XML. IBM, Microsoft, Sun, BEA and other major players sit on these W3C committees, but the standards are open and non-proprietary. In addition to the W3C, the Web Services Interoperability organization (WS-I) has put a finer point on SOAP and WSDL in order to reduce confusion and insure interoperability. By following the WS-I Basic Profile, developers can be reasonably sure that the Web Services they write will work across the broadest possible spectrum. The same companies that support the W3C also support the WS-I, hopefully ensuring that these organizations and their standards will stay in synch. A number of industry specific standards organizations are also using SOAP and WSDL as building blocks for their technology. Most notably, in the e-business arena, ebXML (Electronic Business XML) recommends the use of SOAP for transporting messages.

Bill Heitzeg has been consulting on software development for over 15 years. His company Emerald Software specializes in distributed systems development. Emerald Software has worked with a number of companies to design, develop, implement and test distributed systems. In the past 2 years, Web services have been an essential part of those systems. E-mail Bill at .

-back to top-

---

Methodology Management
by Luis Vigil

Project management software packages provide support for task, resource and time management. Program management software supports collaboration between projects but does not provide facilities for actually managing multiple projects. Shouldn't businesses be able to manage projects both individually and as a portfolio - in an integrated fashion? No simple solution exists for this kind of endeavor; however, the various elements could be integrated to form a seamless program/project management package. This could be called Methodology Management.

At one point, project management (PM) was a stand-alone process managed by a project manager who had almost complete authority to do what was necessary to bring a project to fruition. As more and more projects failed the introduction of a methodology became necessary in order to ensure that fewer projects failed. Projects now fall under some methodology that dictates the documentation required, the phases a project has to pass through, the kind of controls that are required, and the results that have to be met at the end of each phase. An enormous amount of time is spent on the administration of projects. Multiple projects, of course, means that a Program Management Office (PMO) will be established to keep track of all the requirements for each project.

Typically, the PMO dictates that a certain methodology be used. For some reason, this methodology is reinvented in each corporation because we believe that we each have unique requirements. Although there are many PM software packages such as MS Project and Primavera, there are no PMO packages. There are Web based collaborative software packages for managing multiple projects but they are not designed to manage a program. The web, however, does seem to offer the best solution for maintaining a methodology. More needs to be done.

The typical project has a variety of elements; some are not integrated with the whole.

For example, project documentation is diverse and in many cases has a template for each form that is used: the project charter, the business requirements, test plans, quality plans and so on. Although there are some differences in portions of the documents, large amounts are duplicated throughout the project documentation. It seems reasonable to expect that with appropriate software only the incremental information would need to be entered. And that reports could be generated that formatted the documentation to meet specific requirements.

Ideally, Methodology Management software would be able to do more than assign a document to a resource, e.g. Dale is writing the business requirements documentation. It should be able maintain that document as part of its content, and to understand which parts of the document are actual requirements and which parts are project name, project manager name, etc. Similarly when it comes time to generate the test plan, the software should be able to track back to the requirements documentation to ensure that all requirements have been met.

Other areas that tend not be integrated into the project schedule and software are change control and bug tracking. The change control process generally requires documentation to submit a change request, an approval process, a change tracking and verification process, and a recovery mechanism. This is usually not part of a project schedule until a change is necessary. At that point the schedule needs to be modified to include the extra time required by the changes.

Rather than having to go back to the project schedule and modify a task, software could be integrated into the Methodology Management application that handles the entire change management process from change request to schedule change. Typically, change control packages stand alone; these could be integrated into the Methodology Management software.

The idea of including all the documents, change control processes, bug tracking, minutes, meeting schedules and communication plans that are necessary for an entire program under one roof is an exciting concept whose time should come. By doing so, a productivity increase can be achieved.

The requirement would be to manage the methodology with project management type software. In other words, to manage at the methodology level rather than at the project level with project management type software. By managing at the methodology level, various documentation requirements, project schedules, task and resource requirements, change control processes, tracking logs, test and quality plans, and all the myriad and miscellaneous requirements would be integrated into one package.

No longer would a separate software application be needed for change control, project scheduling, quality planning, and etc. No longer would all this information be found in a variety of different locations. No longer would documentation have to be copied from one document to another just to satisfy a template. Imagine the consequences of having some intelligence in the methodology instead of requiring blind obedience from project managers.

It is reasonable to assume that project management began as an attempt to list a number of tasks that needed to be done and probably within a certain time frame. The great builders of the past probably had some way to keep track of all that needed to be done. Project management software has its roots in this kind of scheduling and tracking processes.

With the advent of program management and methodology development, this kind of software is no longer viable. Project management is not just about budgets, tasks and time anymore. There is now a methodology that must be followed with additional requirements that are not easily mapped to the project schedule. There are processes that exist outside of the project plan but heavily influence its completion such as communication plans, risk plans, quality and test plans. The core project schedule still has a variety of tasks that need to be accomplished and resources that need to be assigned; however, it is not a pure schedule anymore. There are outside factors that do not map directly to the development of the product.

Conclusion

A wider, more encompassing, view is necessary. An approach that starts at the methodology level is required. The new software must consider all aspects of project management including those that currently fall outside of its scope. The Methodology Management software must be able to manage projects within the methodology and track each project's progress based on the various stages within the methodology. The software must then be able to track that the project has completed all the requirements for phase 1 planning, phase 2 executing, and phase 3 controlling or whatever methodology is in use at a Program Management Office. The software must be able to interface with change control methodology, issues tracking, bug tracking, task assignments, documentation requirements and every other sundry element required by the methodology. Risk plans, quality plans, and test plans must all be part of the whole - not individual elements of an array of miscellaneous requirements. Program management must embrace an entirely new way of achieving its goals.

Methodology Management must be the new direction in order to reduce the wasted time and effort that is required by constant duplication and template modification. Project and Program management must be integrated into one software package in order to gain productivity and reduce redundancy. Project management is now part of a methodology. It can no longer be a stand-alone process.

Luis Vigil is a consultant with over twenty-five years IT experience. For twenty years he has managed a wide variety of projects. He also has international program management experience. Luis currently works as a Sarbanes-Oxley (Financial and Accounting Disclosure) Auditor.

-back to top-