Things companies can do from the outset to successfully map their way through a mashup:

• Discover business needs in terms of data intersections.
• Build relationships with trusted third-parties from which services, data, and UI artifacts can be shared.
• Involve sales, marketing, and executive management in the process of understanding how your organization’s mashups can be applied.
• Think in terms of flexibility, governance, and security throughout every step of the development process.
• Put into place a process for continuous evaluation and refactoring of mashup components.

The transformation that is taking place across the Internet from a page model to a real-time stream model will surely be affected by [the popularity ranking] phenomenon. Enterprises must be ready to embrace this new model and plan their web presence accordingly or be swept aside by the ever-changing waves of popularity.

For those that have embarked down the open data road to see where it leads, one thing seems to be clear: Exposing data — whether it is internally within an organization or outside to partners, or even the whole world — is a way of thinking about the very nature of the business, more than it is about achieving a one-off end goal. This is because open data seems to create immediate, close, and powerful relationships between the publisher and the consumer of the data, and leads to a series of unexpected outcomes. These relationships can be created with extreme ease with today’s methods over networks like the Web and though often speculative, a good subset of them form rapidly into important ones that can draw in new customers, identify new innovations, head off competitors, or just generate revenue. Witness Twitter and its hundreds of partners accessing the platform (and its enormous audience) through its API or Netflix and its impressively successful prize contest that opened up data selectively to dozens of high-value self-selected contributors as a leading example.

In other words, in order to be competitive with the next generation of businesses, most organizations are going to have to look at open data for reasons involving efficiency, competitiveness, and long term health, particularly as open data enters their particular industry.

1. “Speak the business’s language when defining the problem and recommending solutions.”
2. “Be respectful of the work that has been accomplished to date. Employees are proud of the system they’ve built – even when those systems have reached their expiration date.”
3. “Consider the impact of an IT transformation on all stakeholders – employees, vendors and partners – and train them accordingly.”
4. Encourage IT staffers to speak openly about problems and setbacks. They’ll help identify course corrections and reduce the fear of failure.”
5. “communicate through every phase of the project.”

Performance Tools

1. Paessler AG IP Check Server Monitor
2. Paessler AG PRTG Traffic Grapher
3. Ethereal Network Analyzer
4. Servers Alive
5. Big Brother

Security and Wireless

1. Network Stumbler Wireless Packet Sniffer
2. Kismet
3. Snort
4. Sam Spade

Anti-Spyware

1. Microsoft Windows Defender
2. Lavasoft Ad-Aware Personal
3. Spybot Search & Destroy

1. Have a level of cultural and organizational maturity that supports SOA goals
2. Ensure there is an appropriate balance of investment in shared assets and activities that might only realize benefits in the longer term
3. Organizational separation between provisioning and solution assembly
4. Create a Service Portfolio that is the inventory of enterprise assets from which projects source the capabilities they require
5. Continually assess where you are on the SOA Maturity curve and other appropriate process maturity models
6. Put clear management direction in place for SOA
7. Enjoy the luxury of already having a portfolio of modular systems, built on an inventory of shared components
8. Promote sound software engineering discipline that ensures reuse, consistency and traceability and applied best practices such as component-based development (CBD)
9. Focus SOA attention based on a real compelling event, such as a merger or terminal decline, that instigates strong motivation to re-engineer the portfolio
10. Put a good IT governance framework in place

“Organizations tend to change their structure frequently. The evolving focus on service orientation and globalization will enforce this trend. The world is preparing for network oriented business structures with independent autonomous service providers and service consumers. Parts of the business process will be outsourced to external partners. Departments and business units are transformed to service providers. These service providers no longer focus only internally on the organization, but they are seeking for external markets to offer their services. Everything is moving toward on-demand business where service providers react to impulses – events – from the environment. To excel in a competitive market a high level of autonomy is required, including the freedom to select the appropriate supporting IT-systems. This increasing degree of separation creates a need for loose coupling between application components to be able to have the supported business processes bend unimpeded with the continuously changing composition of the organization structure. To achieve this agility the supporting applications must be agnostic to organizational changes like reshuffling responsibilities and roles, outsourcing or insourcing, splitting up departments or the whole company, fusions and all kinds of other reorganizations. Business processes must not be limited by the supporting IT-systems to smoothly follow all of these organizational changes. If, for instance, part of the process will be outsourced to an external partner, a part of the supporting IT-system will be cut off. The remaining part of the system must start communicating with the external partner. The system must not collapse neither is it desirable that adaption to the new situation costs a lot of money or time. The same is applicable in case of changing partners or in case of insourcing external tasks.”

“In contrast to SOA, EDA provides a way of loose coupling. EDA is not a synchronous command-and-control type of pattern, but just the contrary: an asynchronous publish-and-subscribe type of pattern. The publisher is completely unaware of the subscriber and vice versa; components are loosely coupled in the sense that they only share the semantics of the message.

If you are seeking to support strong cohesion in the business processes, situations where all process steps are under one control, SOA is the way to go. The command-and-control style of SOA – in general – is applicable to:

• Vertical interaction between the hierarchical layers of functional decomposition
• Functional request-and-reply processes such as man-machine dialogues; the user waits for an answer
• Processes with a transactional nature which require commit and rollback facilities
• Data enrichment in a message to be published to bring the message to its full content in a formal format

If you are seeking to support independency between business process steps, EDA is the way to go. This style of architecture is appropriate in federated and autonomous processing environments. Recognizable situations where EDA might be applicable are:

• Horizontal communication between tiers in a process chain
• Workflow type of processes
• Processes that cross recognizable functional organization borders, external (B2B) as well as internal

To find points of decoupling look for parts of the business process of which you are sure they always will stay together in one organizational unit (strong cohesion, atomic business function). In this way a functional composition of the business will arise. The borderlines between the business functions are the points of decoupling. If atomic transactions cross the decoupling borders, then implement compensating rollback transactions at these points.
Striving for loose coupling – and so for flexibility and agility – always is a good idea at all levels of granularity. So a rule of thumb might be: use loose coupling whenever possible and only use command-and-control if required. All of this with respect to the functional dimension for Both EDA and SOA. Of course these principles always must be challenged with performance aspects like required and feasible response times.”