Systems architecting: you either love it or hate it. If you ignore it, however, problems will arise. You might challenge this by claiming that you have not needed it before. But the much anticipated new world of telecom and networking is now unfolding. The combination of convergence and wireless will destroy the comfortable environment in which you were guided by years of history. It will happen when you are forced to implement radically different solutions. Whether the new systems are better will be irrelevant initially; it is the differences that will force you to pay more respect to architecture. Change will invoke questions; questions will need answers; answers will need some rationale. Ideally, the rationale should be found in the architecture, and it should represent an overall plan – not an accident resulting from unrelated projects.
Migrating to a unified enterprise communications system, which handles voice, data and video, and to a wireless environment, which integrates the enterprise and public wireless networks, should not be started without a great deal of planning. The result should be an architecture, which generally consists of four parts: strategies, standards, rules and guidelines. Unfortunately, this is very dry stuff to many technical specialists and managers, and quite often only lip service is paid to it.
There are differences of opinion over the usefulness of architecting within the enterprise. At one extreme is the view that we are mostly technology- and product-driven, and therefore architecting within the enterprise plays a secondary role. At its worst, this approach allows a technical specialist’s allegiance to a particular vendor to drive the direction of technology within the enterprise. At the other extreme is the view that, once developed, architecture is law and no activity proceeds without compliance. At its worst, this approach allows architecture to become an end in itself; it creates unnecessary bureaucracy and stifles progress.
Both views have some validity. The key is flexibility and balance. Architecture must reduce the waste and complexity of re-inventing the wheel on every project, but must be adaptable to technological change.
Proliferation of handheld devices
Let’s consider some examples of the issues to consider in creating an architecture for future enterprise communications. First is rationalizing the proliferation of handheld devices: in addition to the more-familiar types, there will be browser-based, desktop telephones and dual-mode wireless handsets. Second is the direction of wireless local area networks (WLANs) and voice over WLAN (VoWLAN): Should you move from thick to thin wireless access points? Should you wait for dual-mode capability with handoff, or go without handoff, from cellular to WLAN? Third is messaging: Should you view unified messaging from the perspective of the voice-mail system vendor or from that of the e-mail system vendor? What is the role of enterprise instant messaging versus that of public instant messaging? Last, but not least, is the issue of reliability in a converged environment. Do you and the other stakeholders understand the new failure modes and their impacts? Should you consider alternatives to a converged solution in certain cases?
While only scratching the surface, the above list shows the complexity that is emerging. Many of the issues are interrelated and therefore cannot be addressed adequately in isolation. It needs a plan. Managing enterprise communications without the help of an architecture is like managing enterprise finances without a budget.
Ron Scott is principal of Scott & Associates. He can be reached at [email protected]
