A blog for a Startup 2.0 website?

Having a website today is producing some value and not having it, is creating lot of penalties. Traditional enterprise web modeling has lost the concept of static websites for a more dynamic approach where the life of the company is perceived through the web too. Different navigation from the old fashioned menus is needed, user should move on the web site and interact with the website directly by categorizing and commenting all the contents on the website. Blogs are a good way to implement all those functionality in a modern way. Visitors should be able to browse content thought their interests and not through what company want to tell. That's why content's tagging is more important than categories and menu.

A blog entry can be seen as a content, with several information linked; hyperlinks are a good example on the power of linking things and menus are good samples on how contents can be organized.

But, this in direction and through the monopoly of the corporate. Thinking 2.0, contents are coming out from who work and even better can come out from the visitors too. External services like delicious or technoraty enable people to link pages and shares them across the net by tagging them. Thinking of contents as blog entries from the editor community, and tagging as an empirical way of organizing content lets a 2.0 start up company to find what is really important and how visitor are identifying it through the tagsonomy related. A user can browse the site, thought as a set of entries, in different ways starting from the old one through category moving to an editor tag browsing and facing it at the end to the visitor's tag apposed.

This is only because web site's fragments can be referenced with some tag. This can glues either an old fashioned web page, and a dynamic new page where fragment are linked by tags more significantly for the current visitor.

Blog engines like wordpress are fully customizable and have dozen of plugin to interact with entries, tags and outside services like delicious or technoraty.

The next move on the corporate website's chessboard will be to migrate the standard website to a custom blog having some of the blogging featured customized and having the community to work on it editing and tagging content's fragments.

Services vs. Components: Is it a death match?

There's lot of misunderstanding between Components and Services: components are something that aggregates a product for a business behavior while Service is what is doing real business and it's remotely usable from who is really interested in the value added the service is producing.


Nowadays the term service is in every modern acronym (SOA, SAAS, SLA, etc.), and there is non clarification on what is a service and how it differentiate from old fashioned terms like Components.

The term Components come from the manufacture's industry where all those modules are used to build things. It doesn't matter if a car engine is manufactured by Ford or by Subaru, it is produced reusing some of the same components and it is not implemented from the scratch.
During the last years, the Information Technology approach has been to watch other industries and to try to implement all that has succeeded into software. Like in the manufacture, software components are a unit of software that provides business or technical functionality.
Typically they're self-contained and independently deployable. Thinking about a software component we're used to think to:

• a specification (analysis and design) that defines the scope of the component;
• an implementation with any invokable interfaces;
• a module to be deployed (an EJB, a WAR, an EAR, a DLL, etc.).

A component offers its implementation through an interface, that's the unique way a component should be used.

Differently services are focused on satisfying business needs, on a consumer/producer paradigm where the service is producing something valuable for the business. A service can be thought as a set of components and differently from components. A service can be something else than a component. Instead of having an interface service allow the concept of API on different protocol and they can act synchronously or as event's agents.

Another big difference between Services and Components is the way they're reused. Going back to manufacture Components is stored on the shelf and is taken and deployed when necessarily.

Service, in an opposite direction, lives somewhere and is addressed to be used.
It's like going to the post office to send something instead of creating a post office in house.

An approach with components requires a new deployment, new hardware dimensioning and integration while a service approach is only focusing on integration.

What is making the difference?

The way the architectures are thought is making the difference, thinking SOA is benefiting the reuse of value added services and is accelerating the way software is implemented. Every architect is implementing a system, should think a way to make the application addressable and callable by other Service around the network promoting Service Reusability. In terms of business, Service reusability creates a new approach of doing business where specialized companies are providing something that produces real value as a service and is offering a large scale the service at a low price. Google, or salesforce.com or Amazon is again an example of the power of thinking SOA.

Is architecting a 2.0 extendable appliction the same old story?

Architectures are following the way to be extensible, flexible, and easy to be maintained. A 2.0 scenario makes things growing on demand, starting with a small set of features and growing to a huge application with lots of other integrated application (mashup) and complex business logic. Everything shall evolve and redesigned time over time, feature over feature.

The best approach in delivering a modern application is to consider the application itself as a big mashup of the application. This implies, again, a multi-tier approach where there is something in the middle tier that executes something valuable and there's something in the presentation tier that orchestrates business behavior.
Thinking in the way we thought with Enterprise architecture based on EJB and other complex solution, the separation was into the presentation tier, the business tier, and the integration tier.


All the components should be divided into one of the above tears, depending on their roles, and responsibility inside the architecture. Why the separation of roles? Separation of roles can tune the architecture in several point with lots of combination. By implementing modern architecture on social communities, I've found important in differentiating the business tier from the presentation tier: as I do in enterprise architecture with high available technologies. Things and names changes, but the result from the architecture should be the same: having and extendable and flexible system.

The key concept in modern thinking is to separate services their API from their "social interaction" promoting a Widget as a visual coordinator of something is happening backward.




This brings out a reusable API, a first use of the API that is the Social Application and the versatility of the architecture. Having modern API exposed in several formats including JSON restful services, this enabled the idea on having the integration tier as the "presentation tier" or on the old fashioned presentation tier. The modern presentation tier is called Mash up and is really adaptable depending on the needs. If it is required that a machine should do something on the integrated platform (viz. flickr), it can be done at server-side as a restful service. If it is required to operate with some integrated platform visually, it can be called directly from the presentation tier. Yes, this is the first example of how flexible can be an architecture: I can choose to do integration on throttling on the service platform or to choose to go strike through the integrated platform directly from the client interface. This is gained only because, the integrated platform has been tough having the concept of API and that the Social Application is itself a big mash up of those interfaces. Making an API public or private is a tremendous business decision, and should be accurately agreed after heavy consideration. Having a public API makes other the reuse idea instead of the feature copy idea; this requires the company, should also have a clear policy on how integrators can use its API for their mash up. This will be a next big opportunity that 2.0 will create. Stay tuned.