"We now have absolute confidence that what is in iServer, is also what our product contains. Everything’s so much clearer."
Head of Development at EDW
AT A GLANCE
Enterprise Architecture, Portal
EDW Technology is a British software company specialized in developing integrated solutions for energy suppliers. With almost twenty years of industry experience, they are an established player in the marketplace and their flagship product, Energy Retail Suite (ERS), is employed by some of the largest utility companies in the UK.
ERS is a mature solution with an established footprint in the energy and utilities market. Almost two decades of development aimed at answering the demands of the energy market has created an extensive application. However, this was also a real challenge for the company, as it made it difficult for EDW’s various teams to communicate and manage the vast capabilities of the product effectively, and respond rapidly to any issues within the solution. This also resulted in a slow development process.
"We were finding it difficult to appreciate the implications of the changes that were being requested to ERS. Our analysts were unable to easily recognize that, for instance, changing this part here would have an effect on those other parts."
The process of procurement took place along familiar lines. After a number of vendors were examined, the commission decided to advance with iServer. To begin with, for EDW the principal goal right from the start of the project had been to achieve an overarching view of ERS’s functions and the way they are related. As such, having a highly customizable relational database was imperative. What iServer brought forward was the ability to efficiently place information in a structure that was representative of EDW’s Energy Retail Suite. Its central repository and flexible meta-model ensured a single, collaborative, and easily governable environment. This would have a key role in building and managing their product-level architecture successfully.
Secondly, iServer’s Microsoft aligned look and feel, together with its usability recommended it as a no-nonsense, low time to value solution. The platform stood out with its Microsoft Office integration and use of Visio as a modeling environment. These features offered low training overheads, further value creation from existing investments, and a very high user acceptance level. Finally, the ability to relate Office documents to custom objects and diagrams within the database was another major requirement fulfilled by iServer
Three years into their deployment at the time of writing, EDW have successfully achieved their goal of having a clear big picture of their flagship product’s internal make up. Thanks to this newly gained transparency, the company has been able to achieve greater clarity of their product’s capabilities and functions, the way various parts interact, and what areas contribute most to delivering customer value. In turn, this lessened the strain on staff and improved the efficiency of their internal support team, which drove the customer satisfaction levels up.
Still, perhaps the most significant change was the incorporation of a central repository in EDW’s development cycle. EDW not only relies on iServer to store all architectural content, but also to validate the various stages of their product development roadmap. This disciplined, focused approach enables the organization to be in control of their projects. EDW is now an agile company, with quick access to reliable information and an easily navigable product architecture guiding all development.
Typically, businesses procure iServer in order to capture the big organizational picture. By contrast, EDW set out to map out their product’s internal landscape. This makes their iServer deployment somewhat unique. Whereas most companies seek clarity at an enterprise level, EDW wanted to engage in something more granular, effectively a product-level architecture. They sought to capture all the different types of modules and components within the Energy Retail Suite and use iServer to manage all further development.
EDW’s motivation was different than that of most other companies who become Orbus customers. What remained consistent, however, was their architecture practices. Indeed, prior to iServer the company used a mix of Microsoft Office documents and disparate repositories, all the while lacking any standardized architecture documentation. This meant their information was unreliable, which impeded several of their business capabilities.
EDW’s particular needs and their software development pedigree resulted in a very close and highly customized iServer implementation. There were two main reasons behind the success of this project: iServer’s flexible nature, and the fantastic rapport that developed between EDW and Orbus.
At first, EDW were delivered a slightly altered version of iServer. This allowed the team to store so-called configurable items within the repository. The items form a special category in the application and are unique to this deployment. They each have their own properties, and may have custom objects attached to them. Next, with Orbus assistance they created a program whereby repository content would be exported and converted to another format. EDW also set up other programs that would cross-reference that content within the actual ERS environment.
This changed the company’s development practices, basing them around their repository content. When new functionality is added to ERS, the cycle begins with an analysis phase. Let’s say an analyst wishes to add a new business rule, for instance a new wait time for a meter reading. After creating it, they can now record it in iServer. Then, during the development period, a DTSX package will extract content from the repository daily and convert the actual objects and relationships into a .csv format file.
A custom-made portal loads this file and connects to the company’s Oracle database, checking against their ERS environment to ensure only correct objects are present. If the system finds an exception, the relevant stakeholders are notified. This has put EDW in control of the development process and made it possible for them to pinpoint what capabilities they are dealing with and in what way.