In thinking of different ways I could start this article, I thought I could give an explanation for how one could stand out in a crowd when I realized that the really important part of the article is the final result.  Rather than end with the important aspect of the article, and the main reason why I'm writing it, I'm going to lead with the numbers.

Table 1.  Approximate Implementation Dollars

To be clear, the point of this article is not to say or imply any negativity towards the choices made by other companies involved in the same industry-wide project.  There were many companies affected by the project, and each one solved the challenges all of us faced in a way they felt was most beneficial for them at the time.

What I am pointing out in this article is that the implementation choices we made have shown to be very beneficial and cost effective for our company.  In addition, while talking with other companies we have heard the desire of some to change their implementation choices and, in some cases, redo what they've already paid for.  Hindsight can be very enlightening.

In our case, we feel we succeeded in many ways to live up to our members' value of (1) being a cost leader and (2) being agile under different market conditions and regulations.  Early on, we chose to follow the Business Rule Approach methodology, along with similar IT methodologies to implement the changes required of this industry-wide project.  We also made the conscious choice to build our IT systems in-house rather than hire a consultant.  These choices turned into a very successful project implementation within our company with no ongoing maintenance costs.

Background (Case Study)

The electricity market meltdown in 2000 formed the basis for the recent market redesign project (later to be named Market Redesign & Technology Upgrade [MRTU]).  The MRTU project began in 2000 with an initial target implementation date of 2002.  Due to the complexity of the electricity market in California, actual project implementation occurred in April 2009.

During the nine-year lifespan of the project over 10,000 pages of requirements were created by the California Independent System Operator (CA ISO) and provided to market participants (of which we are one) to implement systems within their own companies that were capable of interacting with the new CA ISO systems.  The estimated cost of this project is $1 Billion.

Project Challenges

We faced many challenges during the life of this project, of which I will highlight a few.

1. High Reliability.  Our Settlements department depends upon high reliability of process up time.  It's not how each system works individually; it's how they work together to provide the necessary data the Settlements Analyst requires in order to do their job efficiently and accurately.
   
   
2. Agility Built In.  With the number of requirement changes occurring, it was imperative the technology solutions implemented were flexible and agile enough to be able to accommodate accurate and quick updates.
   
   
3. Cost Control.  It is always important that we have a budget and imperative that we meet it in order to remain competitive for our members.
   
   
4. Evolving Requirements.  Due to many eyes looking at the requirements all of the time, requirements were ever-changing; this was especially apparent during market testing prior to implementation.  At one time we counted 125 requirement changes in one month just in the Settlement portion of the MRTU project.
   
   
5. Large Payloads (data sets).  Introduced with the new project implementation were a variety of payloads depending upon the activity performed.  For this article, I'm going to focus on the Settlement payloads.

We now receive 7 different statement types, and each statement type requires 3 statement files.  In addition, each statement type is received on a different time interval after the actual trading date.

Figure 1.  Large Payload Example

Several implementation challenges were presented with this set-up:

• Our systems need to be capable — to process the large statement files individually.
  
  
• Our systems need to be robust enough — to be able to process one to many statement types and associated statement files on any given day.  We receive an average of 18 files per day.  On one day in August, we received 33 files.
  
  
• Our systems need to be agile enough — to be able to keep track of data for a given day that is sent initially and subsequently updated on multiple timeframes and as far out as 3 years after the initial trading day.

Implementation

As mentioned earlier, we chose to follow the Business Rule Approach methodology along with similar IT methodologies, and we built our IT systems in-house.

An essential element of our approach was to develop our own business language.  This may sound like a given, but it truly wasn't.  Some chose to adopt the terms and rules defined by the CA ISO and, in doing so, left themselves open to all the changes that occurred during the lifespan of the project.

Our business language has been developed using terms, facts, and rules based upon our business.  This solved several challenges around communication.  Being able to communicate clearly and consistently within our organization, as well as with other market participants and the CA ISO, has been a key to our success.  I mentioned earlier that the project involved roughly 10,000 pages of requirements that were ever-changing.  To add to the complexity, not only were the requirements changing, but so too were some of the terms; terms that began as theories were no longer valid several years later as implementation grew closer.  In defining our key business terms and tying them to the terms used throughout the industry we avoided changing our underlying business language.  The CA ISO or other market participants could change their terms as often as they needed without affecting our business.

Once the core business had been defined, IT began to develop systems and processes to meet the requirements of the business.  Our IT department is famous for being on the edge of innovation when it comes to meeting the challenges presented to them by the business.  One of our developers, for example, took on the challenge of processing the large payloads with a (then) new idea of XML DB.  It was a technological solution that had yet to be thoroughly tested and solved our large payload challenge with ease.  Innovation does not come with looking inside the cardboard box.

Our IT implementation ties directly to the business language developed utilizing the Fact Model.  For example, the Object Model used must align with the Fact Model through behaviors.  Similar terminology is also used in order to tie back to the business.  As a real-life example, one of our Developers created the following reminder above his workstation.

Figure 2.  Picture of one of our Developers' Workstation

Throughout the project we relied on three things:

Our ability to change our business rules
Our ability to manage events
Our ability to transform data

The methodologies, tools, and technological solutions we chose were integral parts of our success with all three.

• The Business Rule Repository we use is agile and flexible in allowing for easy and fast rule changes, while also maintaining a history of those changes.  We are able to create, update, or remove any element associated with a business rule at a moment's notice.
  
  
• We choose to reuse business services, which in turn reduces costs.  A Service Orientated Architecture is the foundation for controlling events (or "flash points") and keying processes off of them.
  
  
• The XML DB approach not only solved our challenge of loading large payloads, it also gave us the ability to transform the data.  Once loaded into the system, the data can be easily accessed through queries or developed systems for review, validation, calculation, etc.

Final Results

When all was said and done, 26 different internal systems were impacted by the MRTU project.  Five of those were built in-house specifically for the MRTU project, including the one used by Settlements.  Approximately two years were spent to define our business language as well as to develop and integrate IT systems.  Building a strong yet agile foundation takes time and dedication.  The final product speaks for itself:

Ongoing maintenance after implementation:

Average of 3 to 5 days.

Finally, to end where I began, the numbers speak for themselves.

Table 2.  Approximate Implementation Dollars

# # #