Oliver Bell’s weblog

The technology world is one of many buzzwords and phrases, one that you hear a lot at the moment is “Service Oriented Architecture” or “SOA” which sounds like a highly technical methodology for systems design, in reality SOA techniques can provide a very effective way of dealing with organizational complexity and divides as we work towards delivering cross departmental government services over the web.

During the final months of 1995 I found myself involved for the first time in an eGovernment project. The goal of the project was a simple one, we were tasked with providing a single “Smart Form” that would allow an individual to register as being self employed. Delivering this involved working with business processes in three government agencies, two involved in taxation and one involved in employment registration.

We looked at the challenge ahead as technologies and developers and decided that this would not be a complex system to design or build. After all, it was just a single form, digitising a single well defined process…

About two weeks into the systems analysis phase of the project the enormity of the challenge ahead started to become clearer. Simple data like a name or an address was not stored in the same way across the three agencies. The processes that we were concatenating into our single form were all being run with different service level agreements and delivering on each agreement was quite rightly something that was taken very seriously by the owners of each service. Finally it was also clear that the small amounts of addition overhead of work that would be need to run our single service just didn’t belong in any of the three agencies, and in turn didn’t have any manpower or budget in place to run it.

As a technology company the project soon began to look more like a nightmare than an opportunity, of course for the government we were working with these were exactly the types of lessons that they wanted to learn as they planned for a broader set of projects across the wider civil service.

It is interesting to look back on projects like that today and consider what has changed in the world of technology and how we might approach the project differently in today’s world. The simple answer is that these are exactly the types of challenges that information technology and large systems design principals now take in their stride.

The industry today talks a great deal about Service Oriented Architecture (SOA) which is a technical term for breaking systems into their constituent parts, and then publishing them so they can be used elsewhere while having minimal impact on the organization that provides the service.

In a Government context the advantages are clear. In a SOA world it is no longer critical that data needs to be managed in exactly the same way in every department, or that business processes need to be redesigned with the workings of the rest of the government in mind.

Today every government department can look at the services that it offers, be it licence issuance, tax collection or any other process, and then use simple web service technology to enable those services to be used by other departments or external commercial providers seamlessly.

The benefits are easy to see. Services are less complex and less costly to design and provide. With the right planning around national level architecture and data management, cross government services can be built without the need for costly and complex systems integration projects.

In some cases an agency who makes their particular line of business application available as a web service will find it being used in useful new ways by other government departments or by commercial organizations to provide services to citizens and businesses in ways that had not previously been thought about or funded.

My former team in Redmond put a lot of time and effort into looking at the right high level framework for this sort of environment would look like, the resulting work was called the “Connected Government Framework” or CGF for short. Today you will find the basic framework that the team delivered integrated tightly into many of the solutions and service offerings from Microsoft and our partners.

The lessons from this complex fifteen year journey help us deal with some of tougher issues that just about every government is facing today as they put their own plans in place for the delivery of online and electronic services. Not least of which are the still those same issues of shared service level agreements and data harmonization. Service Oriented Architectures and the technologies involved assist us in delivering complex business systems without the need to closely couple organizations or data in ways that may otherwise be less natural.

23/1/08 additional: Government Computer News this morning carries information on the release of Microsoft’s Citizen Service Platform, an announcement that was made at the Government Leader’s Forum in Berlin yesterday. Follow this link to read more;

Microsoft’s Citizen Service Platform incorporates the company’s work with local and regional governments over the past several years, and consists of templates designed to run in Microsoft operating environments for the most commonly deployed e-government services.

Microsoft will offer the initial set of online services to governments for customization and integration into their current environment later this year.

For computing today interoperability is probably as important to the industry as some of the longer running conversations around subjects such as security and reliability. In previous posts I have talked a great deal about some of my own experience and views in this area.

Interoperability itself has evolved for the computing industry and a growing challenge over the last thirty years. At the start of the journey the picture was a much simpler one than we know today with most systems being delivered by a small collection of very large single vendors, starting with the hardware and storage systems and working right the way up through the stack to the applications that directly serviced the needs of users. At this early point in time interoperability was often defined and resolved by a series of infrequent gateways between the vendors themselves, connecting their large managed customer networks together.

The advent of the desktop personal computer and the consumer operating systems from Microsoft, Apple and more recently the open source community brought with them a new world of consumer choice. Today your desktop system will contain an array of fully interoperable technologies from different vendors who are doubtlessly operating on different continents. The processor, the disk array, the operating system, your applications and your user input devices are all highly interchangeable, and regardless of the choices that you make for each of these components you will still be able to communicate with friends, colleagues and a range of information providers over the common network that we know as the Internet using common sets of applications.

Given the magnitude of these changes many will agree that they have happened in a relatively short period of time. Some questions around what interoperability is or how issues should be resolved are still the subject of significant debate within the industry. Sometimes those debates are driven by large multinational companies who have an interest in one model over another, and more frequently they are driven on a technical level by individuals or groups who can see conflicting methods of solving similar problems.

One of the measures of maturity of any area of science in the involvement of academia in managed research around well defined challenges and real world problems. Interoperability is one area where we are just starting to see academic projects focus on the technical, organizational and semantic language questions that interoperability brings. Every study adds to an evolving view of what the industry needs to do from here, along with delivering well researched data and real world case studies.

As a company Microsoft spends a great deal of time engaging with universities around the world, posing questions that help us gain a better understanding of many aspects of the industry including challenges that our customers are facing and how we need to develop our own plans to support a rapidly evolving landscape.

One such piece of research reached its conclusions earlier this month and was jointly published by the Berkman Centre for the Internet and Society at Harvard Law School and the Research Centre for Information Law at  St. Gallen University in Switzerland.

The conclusions are interesting, and I would encourage you to read the report itself which you will find here rather than just relying on my own observations.

The study itself looks at three use cases for interoperability. DRM in the context of online and offline music, identity management systems and the interactions between web services. There of the key findings can be summarized as follows;

First, interoperability does not mean the same thing in every context. Nor is there the same need for interoperability in every situation. Highly secure systems, for example, will probably not have the same interoperability requirements as consumer systems.

Second, there is no one-size-fits-all method to achieving interoperability in the ICT context. Interoperability can be achieved by multiple means including the licensing of intellectual property, product design, collaboration with partners, development of standards (open or defacto), and governmental action. The best path to interoperability depends greatly upon context and which goals matter most, such as prompting further innovation, providing consumer choice or ease of use, and the spurring of competition in the field.

And third, the report comes to the conclusion that the private sector generally should lead interoperability efforts. The public sector should stand by either to lend a supportive hand or to determine if its involvement is warranted. Trying to impose universal answers can produce unintended consequences such as curtailing innovation, limiting consumer choice, or reducing overall competition.

Given many of the policy debates currently underway in this area across Asia, the third finding requires some more investigation particularly in the context of the joint regional objectives that the industry and governments share in the area of economic development and growth.

Interoperability this, interoperability that… it is clearly an important conversation in our industry today, and one that spans the whole range of vendors, technology areas and end users.

Frequently conversations around interoperability get pulled in the direction of the technology that is in use, but while there is clearly work to be done here it is important to recognize that solving this problem also means tackling a number of other dimensions of the issue.

In 2004 the IDA in Europe issued their first version of the European Interoperability Framework, several IF documents had proceeded it but as far as I remember this was one of the first documents to look beyond the technical issues of interoperability and begin to examine other challenges that would need to be dealt with to provide truly interoperable systems across agencies in Europe.

On a very simplistic level the document broke the interoperability challenge down into three distinct layers;

Technical Interoperability - lets move on…

Semantic interoperability - this involves looking carefully at the language that is in use between agencies and business processes and lays down a goal of harmonizing elements where it made sense to do so. The goal being that a descriptor that might be used to define a part of a process within one agency would be understood to mean exactly the same thing in another agency. If I am tagged as an individual receiving child support benefit in one system then all other systems should know exactly what that means.

Organizational Interoperability - this section talks about something that is clearly a huge challenge for any organization, looking at how business processes intersect and what type of organizational changes need to be made to ensure that those processes work seamlessly together, at least when viewed by the consumer of any resulting service.

 So, with the history lesson over lets get back to the point of this post. Over recent months I have been rolling the IDA model around in my mind, and keeping an eye open for examples of interoperability where only the semantic and organizational layers of the problem have been dealt with to fix a particular business challenge.

Two weeks ago I was at a Microsoft global get together in Thailand and happened to bump into another blogging friend of mine, a chap that some of you will know by the name of Doug Mahugh. Doug has been in the industry for a number of years and has seen several sides of it, as a result he is a great guy to pose questions like this to, and invariably he will always have a smart answer to hand. This time was no exception.

Doug pointed me to an example on ushero.org that talked about the way that the emergency services work together when they are jointly searching disaster zones for signs of survivors or those in need of help. During the conversation Doug talked pretty extensively about the work that took place straight after Hurricane Katrina in New Orleans, and presented a very simple model designed by the US emergency services to allow several different services to work together without duplicating efforts, and at the same time providing very clear communication about the status of the searches between teams on the ground.

As I say, the model is a straight forward one. As a team enters a building they draw a simple stripe on the outside by the door from top right to bottom left, this tells any other team that comes by that the building is currently being checked. When the team is done they draw a second stripe from top left to bottom right that completes an X and then use the four quadrants of the graphic to convey important information about what they found in the building.

Click on the thumbnail above to enlarge the picture and take a look for yourself.

In my view there are lot of lessons to be learned from this by the information technology community. As a community we get very involved in the technical challenges of interoperability when sometimes, as in the case above, a simple change in the design of the business process or the language used to communicate between teams might have been all that it would take to solve the problem that we’re faced with.

Making changes to business process can frequently meet resistance due to a need to involve senior management or other cross sections of the organization, but as the team looking at interoperability of government services in the European Union had already worked out some years ago this is sometimes the quickest and most cost effective way of tackling a given problem.

If you are aware of more examples like this then I would love to hear about them!

We cannot dismiss the technical work that need to be done, and is being done in the area of interoperable systems. 

While it might sound obvious, we often seem to miss the fact that there is great benefit for all involved to look at these issues in the context of the wider business challenge that is being solved.

You might have caught a story in the press today about a translator project that Microsoft and the Digital Accessible Information SYstem (DAISY) Consortium are establishing on SourceForge that will provide both some new functionality in Microsoft Office along with an offline capability to convert Open XML files into DAISY format for use with a range of accessible technologies.

Here is a link to one of the stories from this morning from eWeek, the quote below is from Reed Shaffner, the Program Manager in the Office group who has been working on this from the Microsoft side;

The project is being hosted on SourceForge, with the first beta code expected by early next year and release by March 2008, Shaffner said, noting that the plug-in will work with all Word documents created with Office XP, Office 2003 and the current Office 2007.

“Essentially what will happen is that the plug-in will convert an Open XML file to an intermediate Daisy XML file in the Talk Book format. Customers can then use one of many tools, which are already available, to create a bunch of different accessible outputs, be it Braille or a really rich audio file that allows them to navigate by heading or page number and navigate tables with much more detail than they would typically be able to,” he said.

George Kerscher, secretary general of the DAISY Consortium, explains the DAISY translator plug-in project this way:

“Microsoft’s announcement is monumental in greatly facilitating the availability of text in DAISY books. It provides a clear, production path for organizations and universities who will be able to use the Microsoft plug-in to move into DAISY XML. Putting tools in the hands of people who create content is a giant step toward creating equal access to information … It’s going to move DAISY … from the niche of the libraries for the blind community into the mainstream.”

This project provides both a capability to convert Open XML based documents to the intermediate DAISY format, but will also deliver an open source based reference implementation that any other developer can use when building their own similar translators.

Views and understanding of every topic evolve over time, one of the more “interesting” elements of working for a company as large as Microsoft is that it can take a long time for change to be recognized in the wider marketplace. While internally it is often possible to point to the exact moment when a decision is made it is frequently impossible to highlight the moment in time when the industry accepted that decision as part of the way that the company works.

One example of this is probably our relationship with the open source community. On a regular basis I end up in conversations where there is a general assumption that open source and Microsoft are head to head competitors who cannot face being in the same room together, or partnering to solve customer and industry problems.

If you look back seven or eight years that was probably a very true statement, today however it is a very different story.

In reality most open source development is good for Microsoft, and there are a number of examples of where we are fully supportive of this work. Open source development on the Windows platform brings a number of benefits to our customers, it revolves around developers who are using tools to support the Microsoft platform and in turn build a wider array of application and solution choices for everybody involved.

Open source in itself is not competitive to Microsoft, where there is a clear competitive environment is between products such as Microsoft Windows and Linux or Microsoft Office and OpenOffice.org.

This is especially important when looking at government technology and procurement policy. Today in Asia I seem to encounter two flavours of policy being considered in this area. The first flavour involves governments who are looking at policy to mandate the use of Linux as an operating system within agencies, the second often involves governments putting a pervasive mandate for the use of open source software across all levels of the software stack.

In my opinion neither of these options serve government employees, service providers, citizens or businesses well. Delivery of any computing system in today’s world will involve the selection of best of breed software across the board. This is important due to the differing use cases that platforms are designed against and wide array of choices made by software users both at home and abroad that governments need to interact with.

Microsoft’s commitment to working with the open source community is somewhat diverse, and is designed to deliver an environment where technology interoperability issues are resolved between vendors rather than leaving them for customers to resolve, as the industry as a whole seems to have done in previous years.

Some examples;

• Previous posts have discussed the “Windows Principles” which lay down a very high level framework that is designed to offer unprecedented levels of predictability for any vendor wanting to partner with Microsoft, or build applications on the Windows platform.
• “Interoperability by Design”. In 2003 Bill Gates wrote a public memo with this title, the goal was (and remains) to push the product groups to think hard about interoperability as they go though internal design processes, we’re starting to see the fruits of this work in products such as Office 2007, Windows Vista and the upcoming release of Windows Server 2008.
• Building community. There are a few great examples here, starting with the Interoperability Executive Council where we bring some of the top CIOs in the world to Microsoft’s corporate headquarters about twice a year to discuss the issues that they have with interoperability, some of these CIOs are customers that do a lot of work with Microsoft and some are quite the opposite. Concrete solutions come out of these meetings and again there are examples of product design changes that have resulted from these discussions.
• The second example of building community are the relationships that we’re building with companies like Novell, Linspire, Xandros etc. These partnerships involve the sharing of API information, intellectual property and sometimes code to ensure that interoperability issues get resolved in products before they ship.
• Finally, having worked for the company for almost a decade and a half now I have watched a significant shift in the way that Microsoft thinks about the world of standards. In the mid 90s most standards activity was the responsibility of individual program managers and product groups. Sometimes this worked and sometimes it really did not. Today we have a core team committed to our activity in the standards world, looking both at how we apply the expertise that we have in the existing standards community along with how we standardize some of our own technologies.

Beyond interoperability between open source and Microsoft platforms there are a number of evolving activities that look at how Microsoft builds a closer working relationship and deeper direct involvement in the open source community.

The Solutions Sharing Network (SSN) was probably one of the first examples of this, and directly relates to sharing open source applications between government customers. This was a project that started with a couple of cities in Europe in early 2002, then was officially released for general use in November of the following year. The goal at the time was to provide a safe and secure environment where customers could build communities of practice to share both business practice and solution code. Today the network is supported by a central site called SolShare, and a network of private sites that are in use by many governments around the world.

CodePlex is a more generic project designed to encourage the sharing of projects between developers, today there are almost two thousand live projects running on this shared environment, including many from Asia, a couple of which I have highlighted in previous posts.

A further piece of the jigsaw involves the work that Bill Hilf’’s team have been leading in Redmond, running an interoperability lab where there is a phenomenal level of testing and learning about how Windows works alongside traditionally competitive offerings from the open source community and other vendors.

Finally, out of almost 150,000 projects on SourceForge, one of the premier open source project sites, over 52% are multi-platform and include binaries that will run on the Microsoft Windows platform. From time to time Microsoft has been directly involved with creating projects of our own on SourceForge, most recently including the translator project that is looking at conversion of documents between Open XML and ODF.

So, what is the point I am making here? It is a simple one. Solutions to any technology or technology policy issues will often involve diverse choices from a variety of vendors, and when formulating government technology or procurement policy it is important that every door is left open to allow agencies to choose the best of breed technology to build their solution and interact with their constituents.

The industry as a whole has made some great strides over the last decade to tackle complex interoperability issues, and the open source community is obviously a key component of this. An open source component of a national technology policy can bring some real value, but only alongside all of the other technology that is available in the market.

Over the last few days there has been a lot of discussion in the press and on blogs about some so-called fragmentation in the world of ODF, or the Open Document Format.

Much of the press is centered on the evolving views that members of the Open Document Foundation have around what it means to be a document format in today’s world, and what the future looks like for ODF under current management and maintenance regimes.

The Open Document Foundation would like to see some significant changes made to ODF that will enable compatibility with the billions of office automation documents that exist in the world today, while the powerful corporate forces that sit behind the format in the OASIS ODF TC are not so keen, presumably because of the cost that these significant changes would force upon their development teams.

From a recent NewsBLOG post on News.Com;

“We can’t meet our market requirements with OpenDocument,” said Gary Edwards who started the OpenDocument Foundation last year. “The truth is OpenDocument was never designed to meet market requirements.”

Instead Gary and the team at the Open Document Foundation are advocating focusing their efforts on the W3C Compound Document Format which is still in early stages of development, to quote Gary again from the same article;

“The thing you notice about CDF right away is that you are not working in the confines of how OpenOffice implements lists and tables. ODF directly reflects how OpenOffice does things,” Edwards said.

So, for me the question then comes back to what this all means for policy makers across the Asia region that I have spent time discussing this topic with over the last year or so, and frankly my view is that it doesn’t really mean a great deal, if anything at all.

There has been a lot of focus on ODF in recent months, mainly because an earlier version of the OASIS led format was pushed through the ISO standardization process, then as Open XML was presented for standardization a debate started to rage over which format should be the one true format for storing office automation files. My view and Microsoft’s official position has always been that there is a need and space for multiple document formats in the market place, supporting different users needs.

In reality the push for one true format is a simplistic view of a very complex world, and it denies the lessons of that we have been taught many times by history around such single standard choices in the rapidly advancing world of information technology.

Wikipedia lists 40+ XML based document markup languages, some for specific purposes and some designed for more generic applications. Not one of those file formats will meet all use cases as we know them today in the office automation world. Even with the number of entries documented by Wikipedia editors it is not an extensive list, and we all know that the future holds additional document formats that have either not been written, or not been published as yet.

History teaches us that standards come and go as technology advances, especially in areas where significant and rapid advancements are being made. 

ODF in itself is a pretty tight and elegant standard, but in its current form it does not meet the needs of the vast majority of users of today’s office automation tools. There has been a visible but limited market adoption of the standard. To go further, as Gary very rightly points out, there is still significantly more work to be done before the ODF specification meets the broad generic needs of the 600+ million office automation application users in the world today.

Nobody can predict what decisions will have been taken and what directional changes will have been made in the world of office automation technology by the time this work is complete.

So, what does this drama really mean for the world of open documents? As I say, in my view not a great deal really, this is just the way of things.

What is important for governments and enterprises is that the way that they store their data is well documented , and that there is an assurance that they will be able to access that data many years from now using a range of implementations.

Given the repetitive lessons of the last several decades of computing have taught us, wisdom frequently involves leaving options open whenever possible. Indeed examples that I have discussed before such as x400 email or the TP4 ethernet transport protocols should lead us to be wary of writing any policy that commits to a single standard for anything.

Over the last decade or more I have been involved in a large number of eGovernment projects, some at a national level, some regional and some local government projects.

At the Government Technology Summit in Phuket earlier today we were discussing what to look for in a project to help decide what sort of outcome there will be once it reaches maturity. I have tried to commit a few of those thoughts to this post, some are obvious statements in here (and for that I apologize!) and some that are maybe not so obvious.

As the reader I would ask you to note that at best this these comments are a guide, every project is different and every government is different - the outcome of any project can be affected by the passion of the individuals involved, the desire of citizens or businesses to support the new service or any number of other factors.

So, some things that might be worth while looking out for when you’re assessing chances of success;

• It is never about the technology. I have seen many eGovernment projects have started out as an effort to embrace technology in one form or another without any clear goal to redesign the process that the technology is supporting or a clear policy mandate that supports the end result. Very often these types of project fail. The technology in itself rarely does anything useful if it does not have a really clear business objective to follow. Look for the policy and business agenda.
• It is always about the leadership. Like any process reengineering project, a great eGovernment project has to have a we defined and empowered leader, and that leader generally has to be somebody who is accountable for the business change that the project will bring. Looking back on the many eGovernment projects that I have been involved with success is often driven in association with a committed minister or mayor. The policy mandate has to support the change and the technology that will be necessary for any project to succeed. Look for the leader and listen to what they have to say.
• Policy and Technology in perfect harmony. Technologists and policymakers rarely “connect”. They usually talk two different languages and therefore often their objectives do not align in the way that the project needs. In any project there has to be a component that will ensure that technologists and policy makers talk – before policy is made. Look for the communication plans that bring policy and technology people together in a fruitful manner.
• Knowing the target audience. Knowing exactly who your target users are can be hard for government entities, they generally have to deliver services that reach everybody regardless of disposition. Unfortunately this does not make this point any less important that it would be for any other project. You have to be able to ensure that your end result reaches the constituents that it is designed to assist, and that they can access it on devices that they choose to use. Very often eGovernment projects target the web as a primary delivery channel, in many project it may be better to consider a kiosk, the mobile phones that are in most peoples pockets, digital television services or one of the many other devices that exist in society today. Look for clearly defined and articulate demographics for the target user base along with an analysis of how they want to consume the service.
• Where is the user? All too often technology seems to be the starting point rather than the user (think through some of the current debates that we’re currently having in Asia). Good technology design needs to place the user at the center or it will most likely fail. As with most large projects, focus groups and other ways of gathering feedback from your target user base will be a guiding light as project plans are executed. Look for a clear articulation of the benefit that the user will get from the project once it is complete. Think about how useful your target group of users will find your final project deliverable.
• It isn’t about the Web. eGovernment is rarely about building Web sites or using technology purely for administrative and operational purposes. It’s more often about fundamentally rethinking the way public service delivery happens. For example, would a policymaker commence a new hospital building program if they understood that pervasive healthcare technologies mean that in the near future patients will be able to self-medicate and control many conditions in the comfort of their own home? Look for the pervasive impact that the Internet enabled project is making on policy development and service delivery.
• Measuring success. As with any endeavor, knowing what success looks like makes it much easier to define goals, targets and plans that will get you there. I have seen many eGovernment projects start off as entertaining technology experiments with no specific end goal in mind. Again, these projects rarely seem to get very far! Look for a clear definition of success, make sure it is clear how you will recognize when you get there.
• Embrace the legacy, be ready for tomorrow. Government data centers can at best be described as complex. Over the years business processes are designed and built on whatever the best of breed (or sometimes just the lowest cost) technology of the day is. Any new project needs to be able to be make use of existing components of the data center while providing support for devices and delivery channels that don’t exist yet. In past years when government technology was often designed in a bespoke manner for a single purpose this would have been a near impossible objective, today we can select technologies that are designed to deliver applications over the Internet to huge numbers of people. For government this provides both a clear view into which technologies and standards will be useful today, along with confidence that following the market will provide an evolution path into the future. Look for the plans that adopt technology that is in the market today, then clearly analyses market trends to provide a roadmap around what comes next.
• You’re going to need your people, bring them with you. Very often eGovernment projects involve consolidating service lines to provide seamless services to business and citizens. Naturally this is threatening to some who are measured on delivery of their own service or efficient running of their department. Think about how staff are measured and rewarded, make sure that there is a clear safety net for their careers in a new framework that provides more efficiency, collaboration between departments, and simpler services for citizens and businesses. Look for a framework that supports the people involved and ensures their involvement and commitment to the project.

So, there you have it. This isn’t anywhere near being an exhaustive list, as I said at the start of this post every project is different so the most you can derive from this text is a little helpful guidance. I don’t for a moment believe that I’m an authority on this topic, every project I participate in teaches me something else that eventually needs to get added to this list.

I add that I frequently feel humbled as I watch the complex machinery of government solve process and technology problems on a near unimaginable scale.

If you have additional points that should make it into this list I would love to hear them.

InfoWorld carried a story earlier this week about the interoperability lab that we have established in India, this adds to the labs that we now have in several countries across the region.

The Lab will be focused on both testing interoperability between products from different vendors, and also looking at issues of interoperability between different versions of products from the same vendor.

You can read the article here;

Microsoft has set up a lab in Bangalore where industry, government, and educational institutions can build [and] test applications for their interoperability with open-source and other technologies.

The company also announced Thursday an Open Source Technology Program with four Indian academic institutions. The program will encourage student projects across diverse areas including interoperability between Windows and Linux platforms, said Ravi Venkatesan, chairman of Microsoft India. Venkatesan spoke at an Interoperability Enclave in Bangalore, which representatives of government, academia, and industry attended.

The article is worth a quick read, it also talks briefly about a program that the subsidiary in India have established to support new Independent Software Vendors, and an Innovation Center that has been opened in Pune. (Western India)

A few days ago Jerry Fishenden added a post to his site that talks through how he thinks about Interoperability.

I’ve worked with Jerry on and off for the last ten years or so and I know that a lot of what he has written in this entry is based upon the many discussions and projects that he has been involved in over this time. (and before!)

From his article;

But when the debate moves onto the related subject of “standards”, the discussion becomes more opaque. After all, standards alone do not equal interoperability. It’s looking at the problem from the wrong end - standards are one of several means to an end, not an end in themselves. The equation I always hold in the back of my mind runs along the lines of:

_{interoperability = standards (de facto, de jure) + licensing + partnerships + the real world + (x)}

This is a complex area, unique in that it tends to be complex not because of the technology but more often because of the huge array of ways that people define and use the word “Interoperability”.

The word can carry different meanings depending upon which part of the problem you are most closely connected to or which audience problem you’re trying to solve. For example, interoperability needs for the consumer can be very different to the interoperability challenges faced in an enterprise data center.

When it comes to raw interoperability between technologies the industry has a pretty good idea around how individual problems can be solved, or in cases where the industry has not got it right then you will often find solutions from small software vendors or independent developers.

It is more frequent that you will find the other components of Jerry’s equation are the ones that consume available cycles when working to solve an issue of interoperability, or in many cases they are the components that just get overlooked.

I’m sat here with a huge pile of paperwork preparing for the Government Technology Summit in Phuket later this month. Microsoft is sponsoring an award for technology leadership and the paperwork represents the amazing array of submissions put forwards by governments in Asia and elsewhere in the world. 

Fifteen years ago I was involved in some very early experiments in the United Kingdom to look at smart forms and identity management, it has been astounding to watch technology and policy evolve to deliver the projects that we see today.

Looking at the submissions in front of me I would describe many of them as Phase 3 projects. I’ll explain…

I have watched many eGovernment projects evolve over the years. When it comes to thinking about what comes next for each of these projects I tend to think about their evolution in three phases.

Overall this is probably about as simple as models get, but it does give some clues around how to build a road-map for the delivery of an  online Government service, along with some introspective guidance that relates to the services that you are delivering today.

Phase 1, Presence. Most governments are past this phase these days, but many began here. Early eGovernment projects had the goal of providing basic information about a department of a service through the medium of a web page. Very often these pages would provide a form you could download and print, maybe an address for your local office, or other guidelines around how to work with the department.

Phase 2, Transactions. Today there are a large number of completed and evolving projects in this category. These phase 2 projects very often take an existing business process that has been working for years and set about digitizing it in one way or another, frequently a web form is put online and citizens or business are invited to come and fill it out in this new environment.

In themselves these projects are useful, they make government more accessible and they decrease the amount of paperwork involved in getting something done.

Phase 3, Seamless Services. Ultimately every customer I talk to today about their eGovernment objectives has some element of Seamless Service delivery in their plans. Technologists might describe this as the Web 2.0 goal for government services. To deliver these types of service government has to be ready to think about the business processes that exist today and be ready to redesign them around a model that will deliver a new level of flexibility and openness.

In society today citizens and businesses have access to a wide range of devices, upon which they manage a wide array of data. In the world of Seamless Services those devices play an integral role in engaging with government as part of their everyday purpose, often they will complete government transactions transparently as part of a commercial transaction or another everyday activity. An example might be applying for an electronic visa in your destination country as you purchase the ticket to travel there from an online travel agent.