In my role as an architect within a large enterprise, I then asked myself: Do these principles hold true in the smaller "Web ecosystems" in companies like mine? Are there scaling effects that make those principles only apply to the large as for the overall Internet? I think that some of the principles still apply, others might not, especially those where the number of users must be large to work. I will now go through the principles and validate this.
1. The Web As (a) Platform
Since around 2000, the Browser got accepted as the main application "delivery channel" for off-the-shelf and inhouse developed applications. The main reason for this, though, was that this kind of application removed the burden of deployment from the IT departments. Deployment was, and still is, a difficult topic, so being able to remove this from the list of problems had high priority. But "The Web As a Platform" principle is a much broader concept. Technically, it is about
- simple, yet powerful protocols
- providing end user applications
- providing and using services (web services in "mashup" and other integration szenarios)
- continuous deployment
Strategic positioning: The Web as a platformTo realize this, this means that inhouse developed applications need to provide their data over an API to others inside the company. Hence, besides the regular user interface URL, the developers should add separate SOAP or REST based URLs to their application, making it possible to integrate with the applications very easily. This can then happen on the server side, or on the client side, via "mashups".
User positioning: You control your own data
Core Competencies:
- Services, not packaged software
- Architecture of participation
- Cost-effective scalability
- Remixable data source and data transformations
- Software above the level of a single device
- Harnessing collective intelligence
Typically, Enterprises today are working on this topic by approaching it via the SOA (Service Oriented Architecture). Because there is potentially more control within an Enterprise, all inhouse developed applications should adhere to the pre-defined API standards. My believe here is, that the more light-weight this technology stack will be, the more successful this approach will be. As a side remark: Don't use an ESB.
2. Harnessing Collective Intelligence
Tim refers here to the following features: Hyperlinking, search, collective content ownership, enrichment content by users. This principle also applies to Enterprise IT.
Easy hyperlinking is key here. It must be easy to pick a link to a content element x and put it into another content element y. Hence, links must be stable, and easy to understand.
Search must be easy to use and it must reveal the expected results. Search must be available in different context that make sense to the different user groups. I.e. a single company wide search returns too broad results. If people want to search on certain contexts, they should be able to.
Now for content, the story might be different in Enterprises. Job descriptions and organizational hierarchies do not forsee something like Wikipedia in Enterprises. Goals in your "Management by Objectives" documents do not foster collective content creation at all. Companies try to optimize their knowhow and their intelligence on the level of who they hire. Cross organizational knowhow exchange is still not widely adopted, often it is not wanted. Here's a need of a change of mind on top management, if they want people to accept that others might enhance and improve their content. In most companies, the employees are asked to focus on their tasks, and they should not "wander around and help others" to improve their work. Otherwise, you just might have missed the right job, and a change might be a good thing.
Blogging is a candidate to replace most internal communication channels in the future. However, Enterprises need to have the "push" model available, so Blogs would need to be configured in a way that the target group gets an e-mail when a new post arrived, if it is about "mandatory" information for everybody. Not very Web 2.0-ish, I guess.
3. Data is the next Intel Inside
Leveraging data is also key within Enterprises. I think that Enterprises do not think about their data as an additional source for Internet based use. The famoust use case for this is connecting your own data with geographical information systems like Google Maps. Tim refers to the example of housingmaps.com. The key question here probably is how to make money out of this? Do you create a B2B solution? Do you create a platform with your data, again providing APIs to others to integrate your data with other use cases? If you provide access to your data for free, adding content-related advertisement to your page.
4. End of the Software Release Cycle
Enterprises will like this one. Hey, no weekend deplyoment nightmares anymore? You're welcome. However, for this to happen within an Enterprise, a lot needs to change first. People are afraid that something breaks outside of their control. APIs are changed, so others that depend on those APIs might fail to run. That's difficult to explain to business users. Deplyoment has to be handled most professionally to be successful. That makes Enterprises get much more involved in IT business than they actually would like to. You need an excellent staff to handle this. You probably won't do this for every single application in your portfolio, but just for the core applications.
5. Lightweight Programming Models
This actually reads like a wish-list of probably most Enterprise's CTOs:
- Support lightweight programming models that allow for loosely coupled systems.
- Think syndication, not coordination.
- Design for "hackability" and remixability
6. Software Above the Level of a Single Device
Tim refers to the example of iTunes. I don't think that this makes sense within a single Enterprise. I guess, only a small number of Enterprises have use cases to provide channels with mixed technologies to the outside world. In a broader sense, I imagine that external facing Web sites and applications will need to be designed to run on different devices in the future. Welcome, all you Black Berries and iPhones, do you want to see our content in a sensible way? Remember WAP? Something like this, only the Web 2.0 style.
7. Rich User Experiences
Business users within Enterprises are used to Gmail, Flickr, YouTube, etc. and they ask themselves, why is our IT folks not able to create applications like these. Internal IT departments are acting on this already, standardizing on one or more AJAX frameworks. However, there is a lot to learn for developers and user interface designers when this technolgoy enters the game. We will see a lot of AJAX-enabled applications that do not improve user experiences.
Summary
Most of the principles apply to Enterprises, too. Most IT departments do not react on this yet, however. Most Web applications are still built old school, and those built with new Web 2.0 technologies look like old school applications with some additional AJAX thrown in. Let's hope for an improvement. And for those who are in the position to change something: Let's try.
