In a law firm such as Linklaters the success of the practice depends on the rigorous provision of a
continuously available, fast, secure and global IT infrastructure. Notwithstanding our legal services such as Blue Flag (which delivers legal advice
electronically), the IT department provides context services that support the core function of Linklaters, which is to supply legal facilities on a global scale. Where a firm fails to secure a solid global IT structure, either through lack of spending or poor management, the quality of its core legal service will be contaminated – especially where it is conducting global transactions.
It is rare for a firm to distinguish itself through the IT context service that it supplies, but this is an area that Linklaters believes will strengthen its client relationships and provide a better client service than other law firms. The recent launch of the tailored extranet service clients@linklaters is an example of an IT product that provides a faster, more efficient and seamless global service that cannot be replicated via paper or people.
Clients@linklaters was and will continue to be a huge technology challenge. At a client level the project requires an unprecedented amount of co-ordination and agreement between clients, lawyers and the IT department. Furthermore, each business promise is based on a technology challenge that underpins the entire initiative. That is to open up our systems to support thousands of external users with the same quality of service as we provide internally. So, whereas previously we need only have concerned ourselves with 7,000-plus global users across a secure wide area network (Wan), the challenge now is to open the systems up to tens or hundreds of thousands of users via the internet.
To illustrate the degree of complexity involved in this challenge, let us take as an example one of the many
services clients@linklaters offers: document collaboration. If this is to be a truly transparent offering then it has to be based on the firm’s global document management system. As a result, no matter how clever and skillful our web developers are, or how much money we plough into our servers, the extranet service is entirely dependent on the quality of the deployment of the internal document management system.
So, what do you want first? The bad news or the bad news? Well, first, you cannot create a globally scaleable document management system (DMS) overnight. If your DMS infrastructure is not mature and well supported then that will shine through if you try to base an extranet service on it. But even where there has been substantial investment in the DMS, it will still be exposed in a way that is probably never considered when the system was first purchased.
As a result, co-ordination is required between the extranet developers and DMS experts as early as possible, from the design phase of the project through to load testing and deployment. The onus will be on the DMS administrators to prove they have the ability to handle the expected load levels, while the extranet development team will have to establish that the system will respect the security paradigm of the DMS and include enough safeguards to abstract failures away from the core DMS the lawyers rely on.
Having addressed the technology considerations, there still remains the impact the service will have on the way people work internally. Lawyers have to be made aware that their documents can now be exposed to clients via the extranet and that clients can annotate those documents for review. This means the internal desktop software must be modified to provide the facility to mark documents for external review and notify the user when annotations are submitted.
This is what it takes to provide a real-time view of an internal infrastructure system via the internet. A large enough challenge where you are only providing one service, but a mammoth undertaking in the case of clients@linklaters, which supplies clients with customised views into many of our infrastructure applications including billing, client-relationship management, intellectual property, know-how precedents and Blue Flag to name but a few…
Of course, this service can only be supplied through a high-quality extranet application that is secure, scaleable and open (see sidebar, right). Nevertheless, while the sophistication of our extranet system is a large factor in the success of clients@linklaters, it is the individual tailoring for each of our client’s requirements that has made it stand out.
Orlando Conetta is chief extranet architect at Linklaters.
Transaction servers
Above are two tiers of a typical three-tier architecture used to create applications for deployment either
internally (intranet), with clients (extranet) or globally (internet).
Tier three (infrastructure servers): the internal
systems and databases that are to be exposed over your extranet service.
Referring back to the document collaboration service in the article, this is where your document management server will reside. It is imperative to ensure that you have enough power to handle the load of requests from the transaction server. You may need to scale up your existing infrastructure application.
Tier two (transaction servers): A transaction server is a container for your business objects
(programs) that portray a single consistent view of the services and data in your firm. The transaction server makes your business objects more reliable and efficient at handling large numbers of concurrent transactions. This means your programmers can
concentrate on writing business-specific code that is open to any channel of delivery.
The business object that was written to implement the document collaboration tool is exposed via a web server.
Yet, the very same object can then be used to offer the same service via WebTV, Wap, etc.
For this reason it is not sensible to have your web page templates (ASP/JSP) calling your infrastructure directly, and doing so opens up your architecture to a large security risk.
Tier one: This is the client on his or her browser
connecting via the internet, or it could be the internal systems of another business, or anywhere that can source calls for data.
