Stop selling SOA and start selling REUSE!

Everybody knows that it is stupid to reinvent the wheel. Still, we do it. Over and over again. Why? Because we do not think and breathe reuse. We do not create environments that encourage reuse. We do not make reuse an explicit goal and reward people who reuse things, or who design things so that they can be reused by others.

I think most of the SOA evangelists can agree upon that the main goal of Service Oriented Architecture is to achieve reuse. By reusing things we already have produced once, we can get new products and services faster to the market. We can reduce the costs of producing them since we do not have to spend time and money on developing the same thing over and over again. We can increase the quality of the products and services we provide since they build on proven components. And so on.

To be able to reuse different parts of a system, we must identify the parts which are potentially reusable. We must identify stable and discrete capabilities and isolate them as components. We must describe their interfaces in a way so that we can take the system apart into individual components and put the components together again into the same or a new system. This way we have the freedom of modularity. We can take one component out of a system and put it in another. We can replace a component with another component as long as it provides the same capability and has the same interface. It does not matter how the component looks inside.

If reuse is the goal of SOA the key to all the benefits that SOA promises, then why don't we put more energy in selling the idea of reuse and SOA as a means to achieve reuse? If the idea of sharing and reuse does not stick to our minds and affect how we behave, then reuse will not happen. It does not matter if we design the systems according to the design principles of SOA or not.

Besides, reuse is a much better word to use than SOA. Everybody understands what reuse is about. It is not a something that can be dismissed as a hype, as a buzzword that will eventually be replaced by another buzzwords as the industry gets tired of it. The concept of reuse, of not having to recreate things that already exist, has always been one of the key design principles when we have designed IT systems.

So stop selling SOA with SOA. Sell it with the promise that it can help a business to achieve reuse. Sell it with the promise that it can help t leverage existing assets and make the most out of new assets which need to be produced - as long it is properly combined and aligned with other strategic initiatives for reuse and is seen as a means to achieve reuse.

Interesting SOA (and EIM) readings

Here are two interesting SOA readings from The SOA Magazine.

"SOA in the DoD" by Howard Cohen and Josh Taylor:

The United States Department of Defense (DoD) understands the value of information. While this understanding is very clear, it does not yet have a fully functional or satisfactory prescription for the strategic and technical ailments that pains its communities. Service-oriented architectures are not magic but the concepts, if applied with logic, leadership and continuity, make sense.

Information superiority is key to its success, not only in relation to the military but also for its position as a global leader...//...The primary obstacle to successfully leveraging this data is that it has simply become detached from consumers that have the right and authority to access and use it.

The DoD recognizes that information must be visible, accessible and understandable to the right people at the right time, which is a very serious ailment.

When it comes to leveraging the what SOA has to offer, the real question is not tied up in the technical methodology used to create a mature service-oriented constructs because these methodologies are well-vetted. It is in our leadership's ability to take these methods and apply them in a meaningful way.

"The Benefits of a Data Abstraction Layer for SOA" by Kirstan Vandersluis:

Companies seeking increased agility and reuse through service-oriented architecture quickly find that making sense of widely distributed and disparate data is a major roadblock to achieving the benefits of SOA. To build a successful SOA, architects need to pour the foundation first – they need to begin with a data abstraction layer that makes sense of an otherwise chaotic data landscape.

Data abstraction leads to the ability to leverage physical data, no matter how it's structured, as new, logical schemas that exist only in middleware – creating a common data layer that architects can restructure as needed, rather than making costly changes to the physical database or core services.

This week in links - week 23, 2008

"Already Got an ESB? Read This Before Proceeding with SOA" by Loraine Lawson:

I also couldn’t understand why some people were so passionate about warning us about ESBs as SOA – particular when, as Joe McKendrick recently pointed out,
so many organizations are using ESBs as a simple and useful path to SOA. But after reading this ZapFlash on ESBs and SOA, I finally get it why this is such a hot issue – and a particularly important one for those of you just embarking on service-oriented architecture, but already invested in an ESB solution or two.

ZapThink managing partner Jason Bloomberg does the best job I’ve seen of explaining why this topic is so important and, more importantly, putting ESBs in their place, so to speak. As Bloomberg explains it, the problem isn’t so much whether or not you use an ESB, but rather, how you use it — an important distinction. He says committing to an ESB too early in the process of developing your SOA “substantially increases your risk of failure.”

"IBM’s Zollar: SOA, Web 2.0 drive IT ‘industrialization’" by Joe McKendrick:

It can be argued that SOA itself is a manifestation of IT industrialization, since the methodology promotes the mass production and mass consumption of reusable services, versus custom-crafted applications. Zollar makes the point that SOA, along with Web 2.0 methodologies, are taxing the IT operations expected to support these new approaches, and that the operations themselves need to be “industrialized.

...IT industrialization has only begun...//...Those cursed silos are holding us back again! Of course, SOA — and now Web 2.0 approaches — are breaking down those silos, and, in the process, making it easier and more cost-effective to mass-produce software for the masses. The challenge is that while SOA and Web 2.0 are accelerating the mass production and consumption of software, IT teams are still trying to keep up on a piecemeal, if not manual basis. This calls for deeper automation, or industrialization, of the operations behind the applications, Zollar said.

"Learn from MDM Early Adopters: People & Process Will Continue To Trump Technology" by R “Ray” Wang and Rob Karel:

You'd be hard pressed today to locate a senior executive at a large, public company who hasn't stood in front of her employees, customers, or shareholders and announced that the company's corporate data is a critical asset that must be nurtured and protected. Sound familiar?

Unfortunately, MDM requires much more than rhetoric to survive its adoption barriers. The most common roadblocks cited by early adopters and successful implementation teams include:

• Considering MDM as purely a technology initiative. IT organizations still drive and sponsor many MDM initiatives. Business stakeholders who ultimately define the value of these efforts in improving their business processes provide minimal participation and sponsorship.
• Managing the vast complexity of multiple data domains without proper techniques.
• Assuming that dirty data is just an IT problem. Poor data quality is a critical business barrier.
• Prioritizing funding and managing costs.
• Underestimating the level of executive sponsorship required for success.

"Corporate Information: Asset vs Liability" by David Vellante:

CIOs in regulated and information-intensive businesses (finance, pharmaceuticals, and others) have begun to consider information value in the context of a balance sheet. On the one hand, information is a differentiator and a vital ingredient of transacting business. On the flip side, information has rapidly become a corporate liability where organizations can be charged with wrongdoing based on the discovery of electronic information contained in emails and other non-structured data types.

In the next five years, CIOs face a challenge between introducing technologies to limit corporate risk while at the same time delivering information services that improve business productivity. This is not straightforward...//...the CIO must consider information in the context of risk and value, then balance the tensions between the desire to grow a business and the need to mitigate risk. Make no mistake, as you use technology to limit liabilities, you will handcuff parts of your organization, and information value will decrease.

This week in links - week 22, 2008

"SOA marches on despite U.S. economic troubles, analysts" from ZapThink:

Bloomberg, senior analyst with ZapThink LLC., argues that whatever is happening with the economy it is a mistake to scale back on SOA. "Companies who have been struggling with SOA -- either in the planning or deployment stages -- are at risk of canceling or scaling back their initiatives to their peril," Bloomberg said. "After all, SOA offers cost savings and agility, two essential benefits in good times and bad. What smart organizations are doing is taking a more focused approach to their SOA initiatives, driving toward key business benefits with more rapid, less expensive iterations that show value quickly."

"How SOA and IT are faring in the ‘unrecession’" by Joe McKendrick:

...there has been no apparent impact or downturn in support for SOA projects and initiatives. And we also generally agreed that any rise or fall in SOA’s fortunes will happen regardless of how well or how lousy the economy is doing. But it may be in many organizations’ best interests to look into service orienting.

"Cloud Computing and Content Management" by Alan Pelz-Sharpe, Analyst at CMS Watch:

If there is a buzz around Web 2.0 in the Content Technology community, then there is a roar in the wider IT community around Cloud Computing...//...In fact Cloud Computing simply means moving things to big and bigger Data Centers. Data Centers are anything but fluffy. They are huge, energy-sucking giants -- many the size of small towns. They are environmental disasters and the only thing fluffy about them is the C02 emissions they belch out. Data Centers will in time according to The Uptime Institute become bigger polluters than the aviation industry. Data Centers require massive amounts of energy to operate -- often as much energy is used to cool the centers as to power them. All that heat has to go somewhere. If you think your air conditioning unit is an ecological no-no, then consider the AC demands on a data center the size of 5 football fields, then consider further that according to market research firm IDC, there are over 7,000 major data centers worldwide, and many more in the process of being built. By the way, just because they are big does not make them efficient; it is estimated that around 1/3rd of Data Center servers continually sit idle.

"Study Points to Enterprise 2.0 Perplexity" by Lauren McKay at destinationCRM.com:

Despite steady growth forecasted for Enterprise 2.0, recent research by content management association AIIM demonstrates that organizations are unclear of exactly how to make the best of the Enterprise 2.0 market.

AIIM, which recently introduced an Enterprise 2.0 training program, defines Enterprise 2.0 as: "A system of Web-based technologies that provide rapid and agile collaboration, information sharing, emergence, and integration capabilities in the extended enterprise."

Respondents seem to agree on the goals for Enterprise 2.0, despite not really knowing how to deliver them. Sixty-nine percent of respondents say they wish to use Enterprise 2.0 to increase collaboration. However, they are not clear on which business processes to enhance collaboration.

This week in links - week 20, 2008

"Does ‘SOA lifecycle management’ say it better than ‘SOA governance’?" by Joe McKendrick

These and many other issues were explored at Software AG’s SOA Governance Summit held this week in New York. I had the chance to stop by, and one current
that ran through the event was the thinking that perhaps the industry needs to shift away from the term “SOA governance” — which evokes images of nasty things like control and restrictions — and start referring to it as “SOA lifecycle management.” Will that stick? SOA lifecycle management could be acronymized as SLIM — which evokes images of unwieldy, sprawling service creation and management being streamlined into a nice, manageable process.

Forrester analyst Mike Gilpin planted the seeds for the terminology change, a theme echoed by other speakers throughout the day. However, the bottom line, Gilpin observes, is the fact that “business is still frozen in a mess of technology silos.”

"SOA and the Emperor’s New Clothes" by Loraine Lawson:

For some time now, I’ve been biting my tongue to keep from asking SOA experts one question. A few weeks ago, I couldn’t stand it anymore. Right in the middle of an interview with Miko Matsumura, the vice president and deputy CTO at Software AG, I broke down and blurted out:

'It’s starting to feel like SOA is the famous emperor who thought he was wearing fine threads and in fact he really had no clothes. What would you say to the CIO who is starting to wonder, SOA or any of these three-letter acronyms, are they really wearing any clothes?'

Part of the problem, according to Matsumura, is that we actually have two working versions of SOA. There’s what he calls “Legoland SOA” or Little SOA – which is focused on components – and Big SOA, which is what you get when you add in business process and Web-oriented technologies. Big SOA can be a strategic tool. But, human nature being what it is, people are loathe to give up their little fiefdoms and so, in practice, we wind up with “Little SOA” - pieces and silos, rather than a new strategic architecture. In this climate, SOA becomes “just” something that’s done within IT and never realizes its transformative potential.

"Relating Master Data Management to SOA" by Chris Madrid:

Service-orientation has quickly been adopted for the purpose of abstracting backend complexity from actionable interfaces, LOB applications, and business partners. Once the Service Façade pattern has been applied, backend optimization for performance and maintenance becomes possible. MDM is one technique to assist in that optimization. Existing services are easier to maintain and will perform better. New services will be easier to develop and will become trustworthy to the business without the need for time-consuming data mapping activities.

The foundation for SOA

I have previously addressed "Why EIM is needed for SOA - and vice versa". Eric Roch shares a few experiences which stress the importance of information management to provide a proper foundation for SOA:

SOA really involves a lot of blocking and tackling for IT shops full of heterogeneous systems that must be integrated and disparate data stores that have accumulated over the years. Rationalizing legacy systems and cleaning up data is too much like the old IT grid and it is tempting to put a SOA Band-Aid on top and hope for the best. The problem is the Band-Aid comes off and the festering mess shows through the best of top-down designs.

I have been fortunate to work on many successful SOA engagements that have spanned several years using SOA for integration and information management as a foundation for business process automation and innovation. I have worked with colleagues and experts in the data management field to build a solid information foundation for SOA and seen SOA grow at companies from the ground up – from legacy systems and data up to the presentation layer.

Information is like water - essential to our survival

Being able to communicate is absolutely essential for humans. As social beings, communication is a key part of our lives and what enables us to create and participate in various social structures. As humans, we need to belong to and participate in social groups or communities, from families to nations.

Communication is essential for any kind of collaboration (process two or more people work together toward a common goal). An enterprise can be defined as “…people getting together and collaborating to achieve a common goal” and communication is therefore vital for any enterprise to succeed. Although humans typically communicate and collaborate most effectively when we meet face-to-face in small groups, this is not practical in many situations. We often need to collaborate with people located elsewhere and sometimes we also need to communicate over time. We might also need to communicate with more people than is possible to communicate with face-to-face in a physical meeting. To enable collaboration in these cases, we create messages which we encode into various types of digital content (text, images, video, sound) and make accessible to the intended users via information technologies. In a sense, information could be compared to water:

• Information, like water, is essential to our survival. Given that collaboration is what an enterprise is about, information is also essential for the survival of enterprises.
• Information, like water, needs to be managed so that it is supplied to the enterprise users when and where they need it.
• Information, like water, needs to be of sufficient quality to be suited for its intended uses.
• Information, like water, is managed in a system which collects it from various sources and distributes it to the users.

The analogy with water can also be used to illustrate the purpose of different disciplines dealing with information within enterprises:

• EIM (Enterprise Information Management) is about ensuring that the users will get access to the information (water) whenever or wherever they need it. EIM is about ensuring that the information (water) is consistent, that is it is of sufficient quality and that it will be delivered (flow) to the users in a timely manner.
• MDM (Master Data Management) integrate information (water) from various sources, store it in a repository (reservoir), cleanses (purifies) the information so that it is of sufficient quality, and makes it accessible to any application (water supply system) that needs it.
• SOA is an architectural style that defines how applications (water supply systems) should architected for ensuring interconnectivity, modularity and reuse of key software capabilities (pipes etc).
• Enterprise Architecture (EA) is usually performed by an EA team (city planning department) which besides organizing the business and IT resources so they align with the business strategy also creates the principles, rules and guidelines for how the information (water) should flow throughout the organization (city).

Collaboration and SOA - more than just buzzwords

I tried to answer a question yesterday that I got sent to me via e-mail from an employee at the client company and who is located in Portugal . To be able to answer the question, I had to request information from two persons in my team, one of them being located in Switzerland and one being located in another city in Sweden. In a few minutes I had answered the question and received an e-mail from the employee in Portugal in which he thanked me for the answer. Thanks to the information in my answer, he could continue with his tasks at hand. As I mentioned something about this conversation to my client sitting almost next to me, he said "Isn't it fantastic? That we can sit here and communicate with people all over the world within a few seconds?"

I had to admit that it is quite fantastic. His question got me to reflect on how surreal my current assignment must have seemed just 20 years ago; I am planning and coordinating activities which involve hundreds of people (editors) all over the world, people who are located in countries such as Japan, Sweden, USA, Russia, China, Portugal, and France. I have direct contact with well over fifty of these people, primarily via e-mail or phone. We meet once a year on a conference and then never travel to meet face-to-face.

The project team that I am managing and which is responsible for rolling out new IT solutions to the markets (which we must help all the editors need to learn, prepare and launch) consists of a handful of people. We are partly co-located, but some of the team members work from other locations. We mostly communicate via phone or e-mail and when there is a need for us to meet in a more structured way, we use a web conferencing tool (WebEx from Cisco). We basically never need to travel to get things done. Often, it is just not a viable option. In addition, the corporate policy says that travelling should be avoided for environmental and cost reasons whenever possible.

Although we have much more to do to become more efficient in communicating and collaborating with each other, it is interesting that our biggest headache is not about communicating or collaborating within the project team, with the editors or with all stakeholders in different organizations. No, our biggest headache is the one we get from the constant battle we have to fight with the IT legacy. The problem with the IT legacy is, as usual, that it was not originally designed for the current requirements and that is almost possible to change. The short version is that it is a very complex and lengthy process to get things out to the market (or even at all). Add to that that the inflexible IT legacy adds a lot of extra friction between the ordering organization and the organization supplying it with IT solutions.

I personally both understand and stress the importance of separating the concepts of SOA and web services, one being an architectural style and the other being a technology that can be used for implementing a SOA. Still, I must admit to that web services are excellent for demonstrating key SOA concepts as well as for demonstrating the potential benefits than an organization can get out of SOA. SOA and web services go hand in hand. Even though I now work on the business side and not on the IT side, with people coming from a marketing and business administration background instead of an IT background (I have a combination of both), there is now a common understanding between the ordering organization (“the business”) and the supplying organization ("the IT department") that SOA is the way to go. SOA is no longer just some mysterious or over-hyped buzzword. Why? Because we have all seen a SOA in action.

For a small but essential part of the current solution, core software functionalities and content are now provided to consuming applications via web services. On top of the web services layer, different user experience applications can be designed and developed. Fast. And it can be done by external parties. The latter is virtually impossible today for other parts of the IT platform, even though the task is mostly about presenting existing things in a new way. They will have to navigate in a very complex IT environment and sometimes make changes all the way back to the legacy systems – which of course cannot be changed within the time-frame of the project, so you end up having to scope out functionality and content which would be valuable to end-users. To sum up, new solutions can be delivered much faster since core functionalities and content can be easily reused and thereby shortening development time AND since external capacity can be used to deliver them.

I am absolutely convinced that the keys to empowering enterprises today is to better support communication and collaboration between people and to increase the agility of their IT systems. Improving communication and collaboration is to me a low-hanging fruit since the tools and technologies are out there, although it is a big challenge since it has more to do with people and changing their existing attitudes and behaviors than it has to do with technology. Increasing the agility of the IT systems will in most cases be a costly and potentially very lengthy process, but it is an inevitable investment enterprises need to make if they are to compete on a global and rapidly changing market place.

Insights about SOA

From "Why REST, WS-* and technology are the problem, not the solution" by Steve Jones:

"...I'm really beginning to feel that IT, and most especially the software part, has some form of terrorist organisation going whose job it is to ensure that the business always looks on IT folks with disdain."

"Pitching REST, WS-*, ESBs etc is exactly what SOA should not be doing. Its about time that IT started looking at genuine business cases and signing up to explicit measures. Who cares if you use REST, WS-* or flying monkeys to do something, if you've committed to delivering a 10% increase in sales then the choice is yours."

"By continually pitching a technology centric view of the world IT will continual to marginalise itself and prevent any genuine progress being
made."

From "Whipping the QA Process Into SOA Shape" By Wayne Ariola:

"Provide visibility. When exposing business information internally, or by sharing data with partners externally, the businesses goal is to demonstrate that each part of its system is reliable. Visibility will ultimately promote trust. Trust will ultimately promote reuse of these business assets."

"Internally, the organization has a distinct goal of promoting reuse of business assets. The challenge of reuse is truly a cultural shift in the way that developers and architects have traditionally delivered projects. Given this long-standing cultural barrier, the quality metrics need to tell a very distinct story for the internal constituents. The data should give the internal organization the confidence and trust that the business asset is robust enough for the application. The negative case is also true: The architect should also be able to determine that the service asset is not robust enough for the specific application."

"Promoting trust for an asset must begin early, as soon as the asset is created. Visibility into asset quality helps drive the development cycle and promotes trust for later reuse. In order to promote trust early, the business must define policies that govern the different aspects of the services life cycle, runtime and design time."

From "What is SOA?" by Eric Roch:

"Many IT focused SOA efforts have become an easy mark those selling SOA products since SOA now requires governance software, registries, an ESB, a SOA Suite or what ever the particular vendor is selling. I recently did an audit of a company that spent $18M on software, hardware and services that had no service oriented applications after 18 months with none in sight. The enterprise architecture group designed it all and had it built but no one knew what applications were going to run on it. I was literally told by IT that when I talked to the business that I could not use the term SOA because they already viewed it as a failure. This is the disasterous results that occur all too often when IT shops take this type of approach to SOA."

"Many have set up knowledge bases, best practices, guidance frameworks, and governance processes. And yet these SOA initiatives invariably stall out." Well maybe these companies should have spend less time installing software and building frameworks and more time understanding what business processes could be impacted by removing poor interfaces or eliminating bottlenecks or providing needed information faster (just to name a few). That “stunningly beautiful SOA infrastructure” is worthless without business applications running on it!"

This week in links - week 13, 2008

"Networked economies require Services not Processes" by Steve Jones:

"Back in the 80s the "Value Chain" was key, this was the series of steps and links that it took to deliver the value. Now the Value Chain really suited a process mentality. It was a pretty linear thing, everyone did their own bits in it and handed on from one place to another...//...process made sense in this world, A was followed by B which followed C etc etc. People mapped out simple processes and it just seemed to make sense.

The problem was, and most assuredly is, that Systems Theory was making itself more and more known in the business world. This is where collaboration becomes more about units (services in SOA terms) working together in complex networks than simply a chain which hands over responsibility. This led to the Value Network approach that business schools started pushing out in the late 90s.

The current, and next, generation of businesses are about complex collaborations to deliver value, not simply about following a process. This collaboration approach requires a business service approach and a focus on interactions, objectives and KPIs. Its a much harder environment to be working in than simple Value Chains but the potential rewards, and dangers, are
much more significant."

Here are some excerpts from the post "The best way to sell SOA? Try Web 2.0 techniques" by Joe McKendrick about the convergence of SOA and Web 2.0:

"Web 2.0 addresses the same problems SOA is addressing...Enabling users to easily compose services that make calls to back-end systems will go a long way to helping businesses see the value in SOA"

"Web 2.0 and SOA also have different philosophies...SOA is about empowering the enterprise, and Web 2.0 is about empowering the individual...we want the user to become increasingly more familiar with in the broad Internet, and bring that experience into the enterprise...At the same time, allowing the enterprise to free up its assets, and empower the business user.”

"IT Execs Want More-Effective Collaboration" from PR-USA.net:

"The study, commissioned by Novell, surveyed 100 senior IT executives on their experiences with and plans for collaboration software. A full 80 percent said it is of critical or high importance that individuals in their companies have the ability to collaborate securely within and beyond organizational boundaries, but fewer than half said their current collaboration solutions are extremely or very effective in enabling collaboration among individual knowledge workers or among teams and virtual teams."

"'Providing employees with collaboration tools that enable them to work together effectively, no matter where they may be located, is no longer a wish-list or nice-to-have item – it’s a requirement,' said Kent Erickson, senior vice president and general manager of Workgroup Solutions for Novell. 'But it’s a requirement that is not being adequately addressed for most organizations."

The promise of SOA - Agility and choice

SOA is not an end in itself. It is largely a response from the IT department to the inability of IT systems to be changed as the business requires. At the same time, SOA is also a potential enabler of choice. Let's face it, most of us like choice. But we are still very much stuck in the industrialized era where we as consumers are configuring products rather than consuming personalized services.

To succeed with making SOA an enabler of agility and choice, it requires involvement and commitment from other parts of the business than the IT department. The architectural principles of a SOA (encapsulation, loose coupling, abstraction, service contract, and so forth) must be understood and applied by the entire organization, not only IT part of it. The IT department has always been considered as service to the rest of the business and with SOA the IT department has found a means to make the IT systems truly reflect that. But the IT department should not do this in isolation. Rather, each part of the business should think and organize itself in the same way, as a service provider of resources to the rest of the business. Only then can the promise of SOA in terms of agility and choice be fully realized.

Master Data Management – Benefits And Barriers

Many Enterprises dream about mastering master data and content assets to provide "a single version of the truth". The main point is to be able to identify product, customer, employee, location or similar assets and trust it to be consistent, complete and correct. Master Data Management (MDM) is the common name for these initiatives and a successful approach can yield e.g.:

• Increased business decisions and control
• Better consolidation and reuse
• Improved quality and compliance
• Speed up collaboration and processes
• Setting a foundation for Service Oriented Architecture (SOA)

Some enterprises have started their journey towards MDM. The IT organization is frequently the one that first recognize the needs and defines the requirements. Unfortunately, this also means that the MDM approach is technology centric and habitually concern what MDM solutions to use, not what the solutions should be used for. The usual barriers to success are e.g.

• No directing data and content management strategy
• Absence of a guiding data and content architecture
• Data and content governance mechanisms are missing
• Limited home grown solutions or the use of immature MDM vendor solutions

It is important for the IT organization to understand and promote the awareness of MDM benefits and barriers. The IT people also need to team up and align with the business people and their strategies and improvements initiatives. The best approach for long-term success is to initiate an MDM program that gradually addresses the multifaceted challenges of MDM.

This week in links - week 9, 2008

Google launches online collaboration environment (a future SharePoint killer?):

"Meet Google Sites, the newest addition to the Google Apps product suite. It was designed to allow you to easily create a network of sites and share them with whomever you choose. Google Sites lets you pull together information from across Google Apps by embedding documents, spreadsheets, presentations, videos, and calendars in your sites. Of course, we also harness the power of Google search technology so your search results are always fast and relevant"

"India Outsources to US Tech Workers" by Rajan Chandras:

"The buzz in the local Indian trade magazines is about IBM recently grabbing a multi-year outsourcing deal from the Indian operations of Vodaphone, the global communications giant. Deals like these demonstrate that countries like India and China are more than merely the source of competition for US-based IT firms (and US-based consultants), they offer a solid opportunity for those willing to brave the geographical and culture gap."

"Another view: SOA opening up ‘can of worms’ in organizations" by Joe McKendrick:

"SOA means a change in thinking not only among IT professionals, but among line of business executives and professionals as well. That systems are there to serve them, not the other way around. And they have the power and capability to make adaptations in those systems, easily, whenever they need to be made. And leaders of the organization need to recognize and support this new interaction between people and systems (and that’s going to take a long time)."

"Keeping Employees Productive—What Do You Mean I Can’t Surf the Web?" by Melanie Turek:

"In today’s virtual workplace, where more and more of us work from home or remote offices, far from the prying eyes of our bosses, it’s still frustrating to see how many of them insist on “visibility.” These managers want to know that we’re punching the clock as expected, and that we’re 100% focused on the business at hand when we’re logged in. But it’s better to judge people on what they produce than how they produce it. For some of us, that means reading the comics in between the business news; for others, it’s catching up on the latest You Tube videos. Either way, if we’re doing our jobs well and efficiently, who cares?"

Information centric or information eccentric?

Service orientation has been one of the major IT mantras for some years. Services have been and still are at the center of attention in many business and IT development efforts.

There has recently been a shift in focus from services to information. Information seems to be the next big thing and will be the focal point of many upcoming enterprise initiatives. My fellow blogger, Oscar Berg, has lately presented many statements from different thought leaders that support this finding.

Information and information management has been around for decades, so why a shift in focus now? Maybe it is because a number of people have started to realize that a service without information is an empty shell and a SOA initiative is fragile without a strong information foundation.

The recent hype concerning enterprise/web 2.0 has also put more emphasis on information and its role in business communication and collaboration. Information is today required to break free from application silos and organizational boundaries.

But seeing information as shimmering pearls may lead to the false conclusion that information are more valuable or important than services.

In a typical corporation, people that work with information and data rarely meet or understand people that work with services and applications. They have different mindsets, methodologies and tools.

Therefore, the current move towards information centricity may lead to a better understanding, cooperation and balance between these two groups. But one likely scenario is that the information/data group will see an opportunity to take lead and start doing things their own way, not building on the experiences of the service/application group.

Information (what) and services (how) should be seen as the two sides of the same coin. Being information or service centric is ok. That will help to understand different views of problems and possible solutions. But following the current trend it looks like many are about to go from being service eccentric to becoming information eccentric.

A trail of posts on SOA and organization

I followed a trail of posts about SOA and organization and found some nice stuff along the way, starting from "Tearing down silos, brick by brick" by Joe McKendrick...

"I once heard a rumor that there actually is a company with two integration teams that actually meet and talk once or twice a year. Just a rumor, mind you."

"Lorraine Lawson brought up the whole issue of silos and lack of communication in a recent post, and the implications for SOA. Namely, that SOA not only requires developers to know what other developers are doing, but that the business know what developers are doing, and visa-versa. Lorraine cites the example of one IT professional who had no idea what his coworkers did all day."

"I’ve also heard it said that competency centers also lift SOA matters above the grind of organizational politics. SOA projects can be prioritized according to the needs of the business at large, and not to serve the agenda of one business unit. Essentially, they can be silo-agnostic. (How’s that for a new term?)"

...then to the post by Lorrain Lawson "Overcoming IT Siloes on the Road to SOA Success":

"I’m hoping and, frankly, assuming, that most organizations aren’t quite that dysfunctional. Still, even if your developers are 25 percent more talkative and social than the ones in my friend’s workplace, you can see how organizational issues within IT could be a big barrier for successful service-oriented architecture."

"SOA requires developers to know what other developers are doing – hence, you have repositories and registries. But even with these technology solutions, how the IT organization interacts internally and with the business is a common problem for SOA implementations, says Eric Roch"

...and then back to the post "Organizing for SOA Success" Eric Roch:

"While most IT organizations are focused on the technology aspects of SOA a common barrier to SOA success is IT organization itself and how the organization interacts internally and with the business. IT organizational change is needed for SOA governance including the adoption of a SOA software development lifecycle and the runtime governance of shared services and the components that support them"

"The best practice for SOA organization is to establish a Competency Center to own the services catalog, common schemas and governance processes. But a SOA Competency Center does not just spring up overnight, nor will it address cross-functional barriers without participation from other IT entities."

"To overcome organizational barriers I recommend forming a cross-functional SOA Steering Committee composed of the leader of the enterprise SOA initiative, a lead architect from each functional-application system and an enterprise architect"

...and then finally back to a video clip of a customer (Luxottica) who according to Eric Roch is "linking their success to the SOA organizational structure and roadmap". It is worth checking out. To quote one of the persons appearing in the video, Ken Faw who is Director of Integration Strategies at Perficient:

"We don't have to have a massive governance effort. We have to get it to fit in into the whole evolution of people's intuition, their capacity to absorb it. To me, service-oriented architecture is bigger than the entry point - its the plane, it's the whole transformation of intuition that is going to happen to people, that helps them to become more autonomous agents, working in parallel to achieve multiple business objectives."

Yes folks, there we have the mysterious main ingredient in the recipe of success again: PEOPLE. The main ingredient is not technology, nor is it the organization in itself. It is the people, how they think and behave. And the problem with people is that if you can't do it with them, you can't do it without them either. Wouldn't it be easier if it was all just a technology thing, about bits and bytes?

This week in links - week 6, 2008

Matthew Hodgson writes about the need for more granularity in user roles in order to make the right decisions on what kinds of functional requirements that will meet user needs:

"Do you allow people to comment, review, rate and ask questions on your website’s articles? If you do, you’ll be enjoying the fact that your own users are helping others know what information is valuable on your website. It’s also valuable feedback because it helps you improve the quality of your information. Over the last month, I’ve been working on a strategy for a client to help them introduce this sort of user-to-user and business-to-user interaction. My client though, has until recently, thought of their users in the same way they do their print magazine. This has meant that their market segmentation is broken down into 3 (non-mutually exclusive) roles:

1. those that use the website,
2. those who read the magazine, and
3. those who buy stuff.

Unfortunately, this is not enough granularity to make informed decisions on the functional requirements that are necessary to meet user’s needs. By using the taxonomy of social computing, the market segmentation, and user needs, become much clearer."

Kyle Gabhart argues that EA, SOA, BPM and so forth are all different labels on initiatives trying to address the same kinds of problems in enterprises, such as:

• "Business and IT need tighter alignment
• Visibility between business and IT should be increased
• Governance is needed at various levels of the organization to reduce risk
  and protect ROI
• Business processes and technology solutions should be more flexible and better able to adapt to changing demands
• Business processes and technology solutions should be designed intentionally and with sufficient rigor

The labels attached to these trends vary from enterprise to enterprise. Some drive toward one or more of these goals under the EA umbrella, others under the BPM label, and still others are talking about SOA. Some organizations use two or even all three labels. Regardless of the attached label, it is a strategic initiative at the business unit or enterprise level that aims to improve business predictability and squeeze more value out of technology investments."

Stewart Mader lists 7 strategies from the Society for Information Management's Advanced Practices Council for implementing a successful corporate wiki, the last one being the most important according to me:

"7. Understand wikis are best used in work cultures that encourage collaboration. Without an appropriate fit with the workplace culture, wiki technology will be of limited value in sharing knowledge, ideas and practices. (90-9-1 Theory)"

Speaking of SOA and relationships

SOA marries this, SOA marries that...SOA seems to be in a relationship with or even married to MDM, ECM, BPM, Web 2.0, BI, and many many more - at the same time. Maybe here's the explanation I've been looking for to explain how this can have happened:

Andy Dornan writes about the marriage between SOA and virtualization 2.0 in "SOA's Perfect Mate?":

"Virtualization 2.0 will go beyond server consolidation, making applications more agile and scalable to fit a service-oriented architecture."

John Crupi takes a closer look at the mashup-SOA relationship in "Mashups: Moving SOA Out of The Back Office".

However, everybody seem to agree that SOA and web services are NOT in a relationship. SOA is often misunderstood as the same thing as web services, and vice versa, which is incorrect. Still, I would argue that they are in some sort of relationship. A SOA is an approach to organizing IT resources better, a web service is a type of software implementation (an IT resource) that can be part of a SOA. Both of these two roles exist in most relationships.

Links on collaboration and more

"Increased Investment, More Implementations Expected for Enterprise Web 2.0 Technologies" by C G Lynch in CIO:

"A Forrester report released this week predicts more enterprises will adopt Web 2.0 technologies such as blogs, wikis, RSS and social networking tools. The report attributes the increased