Archive for the ‘SOA’ Category

Scheduling in Telecommunications

Thursday, September 4th, 2008

Telecommunication companies vary widely in their size, customers, products, and networks. Yet they share many common areas where scheduling people are a challenge. A typical telecommunication company has many interconnected IT systems. These systems support the various business units.

Telecommunication IT Systems

These IT systems must also be integrated and communicate with each other. Introducing automated scheduling solutions can be a problem, unless they are designed to be easily integrated into multiple systems.  This is highlighted when we look at functional areas in a telecommunication company and who is impacted by scheduling.

Provisioning

Say you are provisioning a new VPN service.  After the planning and circuit routing is completed, multiple people need to be scheduled to do the provisioning.  Let’s say the new VPN circuit involves four corporate co-location facilities and three customer locations.  Technicians need to be scheduled in a coordinated workflow to configure both the premise and customer equipment.

Operations

The scenario above includes scheduling technicians to be dispatched to install the customer premise equipment. Field dispatch is often part of workforce management. This means that the coordination and scheduling of people is going to have to be done through multiple systems (workforce management and OSS/BSS).

Customer Care

If a residential customer calls in with a DSL line that isn’t working, automated diagnostics are run.  If they determine that the customer premise DSL modem isn’t working, a technician needs to be dispatched to replace the modem. We now need to coordinate information from CRM with operation’s workforce management to schedule the technician to install a new modem.

What do you need to look for in solutions that help automate all of the people scheduling involved in these scenarios?  Customers tell us that they look for:

  1. Visibility of everyone’s calendar (we integrate directly into Microsoft Exchange to make this easy).
  2. The ability to schedule multiple people at once for a specific group of activities (coordinated workflows are a built-in concept in our solution).
  3. 3. Integration with other IT systems needs to be easy (we designed our solution as a Service Oriented Architecture for this reason).

Scheduling is a challenge. This is why we try and make scheduling as easy as possible.

Service Oriented Architecture

Thursday, July 31st, 2008

We talk about our products being designed as a Service Oriented Architecture (SOA).  They are, but why should you care?  This posting attempts to explain why you might.

Historically, software applications were written with few if any open interfaces. These systems were huge, monolithic, and difficult to interface to. The challenge is that these legacy systems contain business logic that implements key decisions about business processes.  Without an easy set of interfaces, these highly valuable units of business logic are locked away, difficult to reuse, and costly to maintain.
SOA Cartool

The concept of SOA was introduced so that those involved in business processes and information technology could design software and business rules as a service. The goal was to make it much easier for companies to reuse software and to interface to SOA applications.

This was helped along by development platforms, like Microsoft’s .NET or Java’s J2EE, which make it easier to both create SOA applications and to interface to an SOA software implementation.  We estimate that it takes 50-75% less implementation work (measured as hours of work) to integrate our scheduling platform into a customer’s IT infrastructure then with comparable non-SOA scheduling solutions.  We achieve these cost savings, even if the customer’s infrastructure is based on legacy mainframe or UNIX platforms.

By being a SOA web service, we also provide customers with leverage to solve multiple business problems. Customers typically purchase and deploy one of our scheduling solutions for a particular business problem such as automating the people and workflow in telecommunication service activations.  This only involves a percentage of all of the employees in the organization. If there are scheduling challenges with another section of the business, our implementation can be used to solve those challenges with a small amount of incremental work.  Traditional business applications can sometimes be applied to new business problems, but rarely can they do so with little work effort.

When SOA is well done it brings greatly reduced integration costs and higher reusability of business logic and application solutions.  That’s why you could care about Service Oriented Architectures.

David Greer

Cartoon courtesy of Geek and Poke