OSS of Start-up CLEC
Raymond Raud
April-May,
2000
Buy or Build OSS Integration OSS "CLEC in the Box" Build It Yourself The Right Strategy
This section is for CLEC's that are drafting their OSS
strategy. It is "Greenfield" in many aspects, but not in
all. Mostly, your business plan dictates what is critical, important,
or irrelevant. Surely, the people who's money you are using for the
venture have their opinions that can not be ignored. So, one size
does not fit all. Below I list the general approaches people have
taken and elaborate the pro's, con's and gotcha's of each. Drop me a
note if you don't find what fits your situation, may be we can
extrapolate from others.
Like with any software, it always starts from simple dilemma "Buy or Build". The answer, like the characteristics of what to buy or build is in your business processes. Most people do not think of like that, but the only reason OSS's exist is to support critical components of your business processes. These processes, in turn, are supporting the competitive advantages of your business plan. For example, if you are planning to attract customers with usage independent service plans, then traditional billing OSS's will be too complex and expensive. Obviously, a pretty good idea of your business processes is required before you a rational selection of the approach and specific implementation strategy can be devised.
Development of telecom business processes is an independent and very interesting topic that calls for a separate discussion. There is a significant amount of work done in the industry on that matter for the base and techniques are known for customization. I'd be happy to discuss how to go about defining them should you be interested in my thoughts. For the rest of this story, let's assume that the processes are defined.
The decision must weight the value of each of the available approaches to your business. The general aspects consider are:
Functionality and support required for the tasks of your process
Functionality offered by the OSS vendors
Cost of the licenses from the vendors
Cost of maintenance from the vendors
Flexibility for changing, extending and modifying the feature set (release schedules, cost)
Availability of pre-integrated solutions that fit your process requirements
Availability of expertise for custom OSS development
Cost and timeframe of custom development
Custom OSS development is generally believed to be risky, complex, expensive and time consuming. It is likely to be quite unpopular with your Venture Capitalist. In fact, this is just one of these popular myths without much business or technical basis. The real risk is to know exactly what you want the OSS to do for you. If you don't then the OSS's can't be critical to your business either, can they? In addition to the business reasoning (theory), there are some successful examples in the industry that prove the myth wrong. Ask if you want to know more.
Here's why:
The OSS business from vendors prospective must produce profit. Selling software to a small market (by number of prospects) commands high price. The license price must cover development cost, sales cost, marketing cost, overhead, and profit. Sales and marketing costs are generally very high reaching 60% and more of the license due to long sales cycles, lengthy testing and trial periods and comprehensive sales tactics. Remaining 40 - 50% must cover all other expenses and produce a reasonable profit.
With historical roots in the industry, where few very large telecom companies developed all their OSS's in-house and for their own needs the "deep and thorough" customization has been common in the industry. A "shrink-wrap" OSS to compete must be very flexible and designed to support majority of known variations of business processes. Balancing generality, performance and flexibility is the vendor's engineering challenge. It takes research to specify, design and develop such software product. The "shrink-wrap" model also makes the development time consuming and costly. In summary, the OSS vendor's development cost (and time) is many times higher than it would to custom develop software for the functionality that one CLEC's needs, but the same software will support a number of other CLEC's too (after lower customization effort).
The time to put a "shrink-wrapped" OSS in service is in average less than custom development, though. A typical OSS deployment (with data loading/conversion and training) is a full-blown project by itself and takes 60 - 120 days realistically. Even 6 - 9 month deployment projects are not uncommon. A six-month development period is about minimum for a custom OSS. Realistic project will take 9 - 12 months.
Considering that the vendor has to recover his research and development cost from few CLEC's with interest and profit the real advantages of using "shrink-wrapped" are shorter time-to-market and custom development project risk. This, of course, applies only if OSS integration is not required.
The "Buy or build" choice has some valid variations.
For example, a CLEC could:
Select and buy OSS's that support specific functions, and integrate yourself
Select and buy OSS's that support specific functions and outsource integration
Select and buy a supports many business functions ("CLEC in a box") the way you need
Find a pre-integrated OSS solution from a vendor that supports your business process
…
Build yourself the functions that need to be supported.
The more "ready made" is the solution, the less it reflects and supports the specifics of your business process. It may be perfectly fine even though it sounds threatening. After all, aren't many of us using Microsoft Word to write our completely proprietary and confidential documents? The key for the choice is identification of critical features for your business now and for the future evolution by the business plan.
Some common sense reasoning stems directly from this critical feature set. If an existing OSS product supports them in manner you require, then it may be better than taking the risk of a software development project. If the OSS does about what you need and much more and is more expensive than you'd assign the value to the support of this function, then it is likely a good candidate for custom development during integration.
It is also critical to consider the sequence that specific business functions must be supported. Generally, the CLEC's need to Sell, Order, Provision, Bill, Monitor, Measure and Report Performance and SLA. Each individual situation may, of course, differ.
In addition to process automation timing (more about this later)
the "right time" for introduction may also depend on
organization's growth needs. More specifically, many functions can be
supported by ad hoc tools like paperclips, spreadsheets, personal
databases etc. The risk of incompatible tools, discrepancies, errors,
missing and inconsistent records grows exponentially with the number
of people that need the same functionality for their activities.
Correspondingly, it becomes costlier to introduce proper tools later
in the organizational development process.
Budgeting
for it Defining the
Integration Development
of Integration Code Testing
and Training Fallacy
of OSS Gateway Toolkits Long
Term Cost of Integration A
Reasonable Integration Strategy Contract
Integration
Integrating OSS's from the components bought from different vendors is the most common approach CLEC's have taken for a while. Various pre-integrated setups with different functionality are appearing from integration companies. This trend has its roots in the complexity and cost of integration CLEC's, vendors and integrators have gone through and learned. The tradeoff of using a pre-integrated OSS Solution versus custom-integrating it from components is the same as with "OSS in the box" approach. Therefore, it is pointless to describe it in any further detail.
Custom integrated OSS solution can be made efficiently supporting
your unique business process. If that is a key competitive advantage
for your business plan, then it is viable approach. Like the network
infrastructure, your OSS solution is a unique system. Like network,
it needs enhancement, evolution, lifecycle maintenance etc. that is
part of the operation cost.
Different from the network equipment, OSS's support your
business even if they are not integrated. Therefore, the cost-savings
and additional revenues must justify the integration expense. The
integration can be gradual, evolving with the business processes and
applied where the highest impact can be achieved. Besides
streamlining the organization and shortening the time for tasks in
the borderline of autonomous OSS's it is important to estimate and
add the cost-savings from the accuracy of your databases. Clearly,
each manual data entry is the source for errors in addition to the
added task time. The errors introduced by manual entry (or lack of
it) has much larger effect on the cost as these errors typically
cause inefficient use of network resources, lost service, lost
customers and revenues. Finding/fixing requires high skill expensive
staff, lots of patience and time.
Statistics on the average error rates and their cost is available
in the industry. It certainly varies with CLEC, but generally
steadily increases the longer the situation is uncontrolled.
Integrating OSS's into a solution is a complex activity
because it requires through understanding of the functionality and
interfaces of all components in addition to deployment of individual
OSS's, integration software engineering, business processes, vendor
release schedule, staff training and organization's change
management. All mentioned aspects are intertwined and relevant for
the success of the project.
First in sequence is development of the specification for the integration project. It requires study of the business processes, complete documentation of all integration aspects that include function as well as data exchange needs, frequency, change notification mechanism, impact of the integration on the performance of each of the OSS's, identification of data elements and entity identification schemas. Specification of integration is an intellectual effort that requires high skills and experience
For the source material this phase requires documentation of component OSS interfaces at the time the integration development starts (Note that the vendor release schedules may affect the interface). The vendor development organization's support is highly desirable because the documentation is most likely inaccurate or incomplete in some aspects. Surfacing these issues early helps to avoid later costly re-developments. Having CORBA IDL or DCOM IDL definitions helps because it formalizes the syntactic aspects of the interface. None of them replaces the description interface semantics. Complete UML definition of the interface can alleviate this need, but care must be taken for the accuracy and completeness.
As Figure 1 illustrates this activity compares the interfaces of OSS's pair wise and via "cap analysis" produces the specification of the functionality for operation invocation, identification and transformation of needed data elements. This, in turn, serves as input for project effort and cost estimates, scheduling, test plans etc.
Figure 1: Integration Specification Development
Having the cap analysis in UML is beneficial as it serves for
unambiguous input for the software development group, provides
commonly understandable documentation. UML tools usually provide some
features for checking the completeness and accuracy of the
specification. Having the UML business process definitions will help
to reduce the time and cost of this phase.
From a proper specification code development does not require
special skills and setup. The developers can produce the detailed
designs by directly detailing the UML specification constructs and
often generate the interfaces and part of the code.
Since testing OSS interfaces is not a one-time activity it is
desirable to negotiate wit the vendor a special low cost (or no-cost)
license for the integration lab. Trying superficially tested
integration code in "live network" requires special risk
mitigation measures, is costlier and takes longer. Yet, it can be
done and is a viable option if the number of integrated interfaces is
low.
A thorough test plan that covers all possible operation invocation
and data exchange scenarios is necessary. The test plan, test data
and expected results should be archived for regression testing after
upgrades.
Figure 2: Combining Testing and Training
Testing activity can be combined with user training as illustrated
in Figure 2.
Developing the integration code involves repetitive and
similar operations. This realization and the relatively large amount
of integration work around have created a set of integration gateway
tool vendors that claim to automate the code development. No doubt,
their claims are true. Use of the tools still requires specification
and thorough testing. Since the integration software development
itself is not extensive, time consuming nor expensive, the effect of
this automation is relatively small. The exceptions are integration
with legacy mainframe OSS's that do not provide any of the
integration-friendly interfaces of newer OSS's.
It is important to understand that OSS integration is not a
one-time project. Its real cost is in maintenance of the custom
integration code, not in the first integration effort. It comes from
the lifecycle of your OSS solution.
The component OSS vendors will agree to maintain their OSS's as long as you keep your version upgraded. Typical maintenance policy requires (or becomes prohibitively expensive) supportable version not to be more than two releases behind. This is not because the vendors want to squeeze the most money out of their customers, but because it becomes very complex and costly for them to support a long sequence of old releases. Buying their OSS license you agreed to support their business strategy and that always calls for continuous enhancements and upgrades with 6 - 12 month release cycle.
The same applies to all component OSS vendors, just that their release schedules are not synchronized. Of course, they can not guarantee to maintain full backward compatibility of all the interface features that your custom integration code relies on, so each upgrade turns into full regression testing cycle with potentially some changes in the integration code. Since you are the integrator -- you must maintain staff with expertise and lab environment for such an upgrade compatibility testing. The best would be to keep the original development staff for maintenance as they have already "learned" the code. This may introduce a fixed cost that is difficult to justify after the first big development effort is over. It also creates a career development issue. The software engineers generally want to do something new, rather than "dig around in old code".
The ongoing fixed cost, organizational and staffing issues that
makes the custom integrated OSS solution expensive over time.
A reasonable integration strategy keeps the fixed cost
constant by scheduling OSS integration few interfaces at the time
reducing the need for large software engineering and telecom systems
engineering staff. With this approach the complexity lies in project
management that balances the timing for deployment of streamlined
process support, training, and vendor releases with minimum
engineering staff and change management (see Figure 3).
Figure 3: Integration Project Management Challenges
This activity requires careful planning and synchronization with business process evolution. The dependencies between the required staff productivity and supporting OSS capabilities becomes critical for timely introduction of new OSS's and streamlining the support by integration. The correct timing must consider the length of staff training and the dip of productivity after introduction of any new facility into the process. The Figure 4 illustrates Ordering process automation timing.
Figure 4: Timing the OSS Support Introduction
Note, the reduced productivity (transaction volume) during the
training despite of increased staffing level.
Outsourcing the integration is always an alternative to doing
it in house. The process, issues and problems are no different for
the integration vendor. If the integrated OSS represents a key
success factor for you then the main concern is not the first
integration effort. The main concern is motivating the integration
vendor to maintain the same level of attention to the process
throughout the lifecycle of the integrated OSS solution. It is likely
to cost more than "do it yourself", but now you must be
very interested to keep the integration vendor in business for the
lifecycle of this integrated OSS solution.
Like the name says, these OSS's support most functions that
most CLEC's need. The tradeoff is obvious, it provides generic
support for common business processes. If you plan to compete on
something else but price and your profit margin, then that may not be
a good choice. On the positive side, there are no integration or
development issues. You'll deal with one vendor. Of course, you will
depend on its success, but so do some of your competitors.
The key for the decision must be if this system can support you initially and can it grow to where you want to be. Of course, the salesman tells you that they can do miracles. It takes some research to find out how simple it actually is to extend and enhance the system outside of what the vendor's release plan contains. Which company(s) can do this and what they think this will cost you?
Some of "CLEC in the Box" are very complex systems,
because they are not partitioned properly. A complex and intertwined
database schema can cause a lot of trouble down the road. It may have
become complex because the people where implementing many functions
in the same database (do not confuse database with tables) for
performance. With today's technology this is a handicap of legacy
architecture, not a benefit. Even simple data loading can require
highly specialized consultants (you guessed it right, they will cost
a lot). Make sure that these issues are clear besides that the
product is the "best of breed", "state of the art"
and from a " a world leading OSS vendor" before you sign
the contract.
Tougher than to do it is likely going to be to sell this idea
to your venture capitalists. You can not convince them that there is
no risk in this project. It will definitely cost you money, take time
and dilute the focus. Here are some word of advise, should you be
courageous to propose it and successful to get the project approved.
The beginning of a successful Integrated OSS development process is not any different. It all starts from processes that are molded by the business plan, competitive advantage, timeframes etc. To avoid scalability and performance surprises down the road it is recommended to call in consultants and do the whole specification work upfront. The specification must also break the whole project into independently deployable and usable phases that can be developed by approximately the same number of software engineers in required timeframe. Likewise, the developers should do the high level design for the whole system before starting to implement the first phase. Consultants are help for these tasks. You'll avoid them becoming your fixed cost once the specification and design are done. A better alternative are employees with extensive telecom operations experience that will be switched to other tasks once the specification and design are done. They are better because they stick around and carry some of the responsibility of updates and modifications over time.
The OSS design must cover the needs of your business and required evolution of your OSS's. You'd likely build a set of database applications. Keep them as independent as possible with very clearly defined functions and interfaces. This will ease maintenance, operation and enhancement. If needed, these independent applications can be replaced one at the time without affecting others. Keeping it simple also makes development fast and simple, testing straightforward and thorough. Following KISS (keep it simple … ) principle is the best policy for development project risk mitigation.
You'd need 6 - 12 months and a dedicated team to get your OSS up and running. You'll save money if the team has a strong leader who knows what exactly must be built. There are always at least 1001 different ways to design and develop exactly the same software. Pondering about the alternatives with an attempt to optimize will just waste time without enough return to justify the cost.
The overall cost can be best estimated from specifications. It
will probably about the same money as if you'd buy because of the
reasons discussed above. Your real problem is maintenance. Yet, it is
no different from maintaining your own OSS integration. The same
issues are relevant and same solutions apply.
Of course, there is always THE "right strategy". The
choice is always individual and depends on Pro's and Con's of
specific situation. The list of considerations must include
availability of skilled systems engineering and software development
staff, OSS solution lifecycle issues along with managing change in
the organization, rational and political aspects within the
organization and with your strategic partners. None of the above
should be interpreted like an exhaustive list of alternatives and all
of the above can be used in any combination that makes sense.
Most importantly, any software you buy or build must be the enabler of the goals and methods set forth in the business plan. Rational choice is not possible without explicit business goals because "any road will take you there if you don't know where do you want to go". There are always many ways to achieve it. Debating which is the best, takes longer than the benefits of the choice can justify.
Comments, questions, objections?
Thank you,
Raymond
Raud
© 2000, Raymond Raud. All Rights Reserved.
Last Modified: August, 2000