|
|
By Tim Young
In considering the issue of Standards,
Pipeline took a moment to speak with
Keith Willetts, Founder and Chairman
of the TeleManagement Forum, industry
consultant, and general expert on the
space. Here's what he had to say:
Q: Thanks for taking the opportunity
to speak with us, Keith. TMF is obviously
a leader in the area of standards.
Why are standards so important to telecommunications?
A: Well, if you go right down to a basic
level, mankind would never have built
the most complicated machine on the planet,
the global phone system, without some
basic ability to plug it all together.
Standards have been important in telecom
since Alexander Graham Bell, really.
We engage in network standards. We're
more of an IT organization, looking at
how the the business processes and systems
that sit behind the networks and services
actually get built, delivered, billed,
and so on.
Historically, there hasn't
been much of a desire for standards.
Every operator built it their way and
that was just fine. In the last decade
or so, the cost of building all of that
custom software and trying to change
it rapidly has just started to kill service
providers. Particularly, every dollar
spent on software means another five
dollars integrating it. This so-called
'integration tax' has become a huge issue.
It takes so long to integrate systems
together and costs so much that there
has been a rising desire for software
that you can plug together. The desire
for standardization has really grown
out of a need to reduce cost. A need
to reduce complexity. A need to move
much faster to change the way the operational
processes behind the scenes hang together.
We're seeing that not just across the
telecom industry, but across the software
industry. If you look at the website
for Oracle, or even Microsoft these days,
they're talking more about software standards
more and more. There's a new reason coming
over the hill, as well, and that is this
whole
|
|
“Particularly, every dollar
spent on software means another five
dollars integrating it. This so-called
'integration tax' has become a huge
issue.” |
|
convergence issue. No longer
does a service provider do
their own thing and put a service
together and out it goes. Those
services are comprised of other
partners in the value chain.
How do you get all of those
partners to line up and provide
a product that works? So there
are more reasons driving it,
and we provide standards for
operating systems.
Q: Is the fact that standards
haven't been adopted sooner
the product of general malaise
and a low priority for standardization,
or has there been active
resistance from companies
that have proprietary software
they want to maintain?
A: There are a lot of issues
in that. We do standards at different
levels. We do something we call
frameworks, which are a guidance
for how telecom operators should
be putting their systems together.
The first things that starts
with are not software standards
at all, but rather what are the
business processes that are going
to be automated with this software.
Can we agree on some basic fundamentals
for how you run a telecom service?
This is not something you can
performance test to, but the
guidance is pretty comprehensive
in the way it lays out the landscape.
We've got the same thing in the
area of data standardization,
and of how you would go about
ensuring that all the things
you want to exchange information
on are portrayed in a common
way. Then you get right down
to specifics, the equivalent
to the USB port on the PC. The
specific 'It either works or
it doesn't work' software standards.
We have a program called Prosspero,
which is out plug and play standard.
When you get down to the specific
plug and play sockets, along
comes a new bit of technology
like IMS or SDP and all of a
sudden people identify a need
for a specific plug-in socket,
and then you have to move quickly.
In the past, that's been a lengthy
process. A bunch of guys identify
a need and work together, and
exchange emails, and sit in smoke-filled
rooms and write on flip charts.
That method takes a long time,
even if you use lots of collaboration
tools and web techniques to speed
that up. What we're moving to
now is more of a software contribution
approach. If anyone out there
has met this problem before,
did you develop software that
helped you overcome it? Does
it conform to our requirements?
Does it have some test tools
with it? We can fast-track that
into Prosspero as a contribution
from one
article
page | 1 |
2 | 3 | |
|
|
|
|
|
