Capping IT Off
Together, Free Your Energies

A New Landscape: SAP in the Amazon Cloud

Last year, Capgemini’s VP of Packages, John Waymire challenged the SAP Solution Centre here to put SAP ‘in the Cloud’. A small team of us took up the challenge and started looking into how the public Amazon Cloud (Amazon Web Services or AWS Cloud) could be used.

SAP is deeply involved in the AWS Cloud and has been supporting the company’s internal systems since 2008 (see a video here and a wiki here). As a SAP Partner, Capgemini leveraged its strong relationship with the company to deploy a Proof of Concept (POC) landscape in the AWS Cloud in October 2009.

I’m pleased to say, it’s 2010 and the challenge has been met. Our SAP Solution Centre boasts a solid understanding of SAP in an Amazon Cloud environment. How? Simple. We put SAP in the Cloud to prove to ourselves it could be done, then built it for our clients to spread the word.

So what exactly did we build?

Currently the SAP Solution Centre has a Proof of Concept (POC) laboratory running in the AWS Cloud, primarily on Windows, but also on Linux-based servers, a key part of our next phase of development.

As the person responsible for the technical aspects of the landscape, I was part of the team that deployed, at various stages, the following systems from the SAP Business Suite 7 portfolio:

After signing a contract with a major British Utilities services company just before Christmas, the newly appointed Capgemini project team quickly found that there was no way to provision the required hardware for a blueprint system through normal channels. The project had to start within days of the contracts being signed, and the team was ready to move across multiple geographies.

In order to keep the contract on-time and on-budget, and ensure the climate was right to commence, it was decided to build or ’stand up’ the environment in the AWS Cloud. In four days we were able to build the above landscape in the AWS Cloud and have it ready for functional consultants to begin and complete work in 48 hours. In a traditional hosting environment this landscape would have taken weeks to create, simply because of the number of people it involves.

However, rapid deployment is not the only driver for the AWS Cloud as cost is also a key benefit. The solution outlined above has been deployed for approximately 40% of the cost of a standard hosting landscape. So successful was the deployment, it turned heads within our SAP Solution Centre. Within days, several consultants were exploring what part of their SAP landscapes could be put into an AWS Cloud.

This is a new and fresh challenge, as we seek to ensure that this solution is only used at the right time and in the right way. To that end, below is a framework that the Capgemini team has constructed to assess whether or not a solution can be deployed safely in the AWS Cloud.

Some of the high level criteria are:

·         Time constraints - How quickly do the systems really need to be available?  

o    Everyone wants their systems immediately, but when does the system actually need to be available?

·         Cost requirements - What are the cost drivers for the customer?  

o   Of course everyone wants to use the least costly option, but some drivers for reducing costs are more compelling than others, and they should not be taken at the expense of the project outcomes

·         Who is responsible for provision of the systems? - Is it Capgemini or the client?

o    This has a huge bearing on whether a landscape can and should be deployed into the AWS Cloud.

·         SLAs - Is there an SLA for service provision?  

o   The AWS Cloud has no SLAs in place for a normal account, it is built upon the concept of disposable servers and computing power

·         Access requirements - Who needs access and from where?

·         Data security - What sort of data will be held within the system?  

o   Although AWS has passed several security certifications, there is still some fine tuning required to the security model in relation to SAP

During the last 5 months, we have been able to move from a theoretical exercise of deploying SAP in the cloud to actually having a live SAP project deployed for a major British company as part of an overall programme that runs into the £100’s of millions. The learning curve has been substantial, especially moving from a POC environment to a live environment, as there are many things that are often forgotten in a POC. We have encountered several challenges during our landscape deployments, but we have resolved them and provided more functional and flexible environments in doing so. Technology always moves quickly, and all too often companies are guilty of claiming they can do something or that something is possible before it’s actually been done. We’re proud to say that we’ve not fallen into that trap.

In terms of next steps, Capgemini is working exclusively with SAP to provide better applications to help manage systems in the AWS Cloud and to expand our expertise into other areas, like SAP on a Windows Azure platform or IBM’s Compute Cloud. Following our success with Amazon, both companies are very interested in working with Capgemini to deploy SAP landscapes on their Cloud platforms.

The possibilities that the Cloud presents are immense, and on a personal level, I honestly can’t remember being so excited about being involved with something at such an early stage. However, in order to realise those immense possibilities, we as trusted advisors must guide our customers to use the right tools and methodologies at the right times. We must not allow ourselves to be prejudiced against traditional methods if they are right for the circumstances. This can spoil the party for everyone.

This entry was written by Chris Kernaghan. Chris works in the SAP Solution Centre within Technology Services in Capgemini UK, he specialises in SAP upgrades and infrastructure migrations.

Digg this Digg this | Seed Newsvine Seed Newsvine | | Posted by Rick Mans on February 9, 2010 in Invisible Infostructure | Comments (0) | TrackBacks (0)

Too much thought will kill you

The design utopia in which consultancy firms and Dutch government agencies have been participating in for decades has been suprising me for a while now. What especially surprises me, is that the promise of a young discipline, Business Rules Management or BRM often is equal to huge reports, huge architectures, a lot more design and in the end a governmental IT organization which has a new paradigm, and maybe a new tool without the commitment of the business. We as consultancy firms earn loads of money at times without provable improvement of the business of organizations, only less trees in the world. What I missed in this story thus far, is the commitment to and from the business. And that`s where things often go wrong. The promise of BRM was putting the business 'in control' of her business logic. In that way the business would be able to make better decisions in processes, savoring crucial business knowledge for the organization and building systems that could be changed by the business itself. In short, we`ve got to win the hearts and minds of the business!

There is a world to be won here. The business is not waiting for a new report and beautiful stories of how the world could be, as the penguin said in the movie Madagascar, don`t give me excuses, give me results! In other words, fix my (business) problems, and fix them now!

In the past the business explained it`s wishes to a programmer who would build a program, which sort of did the trick. Hey, talking to programmers was tough back in the day! After that, we had functional designers, technical designers who talked the language of the business (sort of), who in turn talked to the programmer. Nowadays, it`s total chaos with architects, designers, analysts, programmers, UI specialists and loads of other consultancy roles. They all like to design the world of the client using the latest 'hot' methods and techniques. But the business is not waiting for business services, SOA, WOA, ESB, and more of those beautiful concepts. No, shop is open, and it needs to change, 24/7! The business needs to do some of the changing to IT stuff themselves, the stuff they really need.

And who knows better which stuff they need in everyday business, it`s the business themselves. It would be best if we just helped them along a little, a nudge in the right way. And especially the business knows how to implement those business changes. And that`s where we are supposed to kick in, call it Agile Collaborative Business Technology if you will (to keep it simple).

My advice:


  • Organize BRM projects in a capacity building way (looking over the shoulder, collaborating, do it yourself) in this way when we`re gone the business can and will survive;

  • Start BRM projects small but practical (Prototype/POC from the get go), with a real to solve business issue;

  • Design parallel and mostly supportive of the 'real life'BRM projects , business changes faster than you can design! and

  • Introduce with the start of BRM project a new role in the business organization, one of the business engineer, and give him ownership of applicable business logic.

Digg this Digg this | Seed Newsvine Seed Newsvine | | Posted by Bjorn De Visser on February 8, 2010 in Agile | Comments (0) | TrackBacks (0)

Weekly digest of week 5 2010

This week the big news that you can play Tetris on your TV, a demonstration of 3D with CSS, subscriptions are becoming more and more important and social search is about mobile and not about Google.

Light reading:

Rick Mans is a social media evangelist within Capgemini. You can follow and connect with him via Twitter or Delicious

Digg this Digg this | Seed Newsvine Seed Newsvine | | Posted by Rick Mans on February 8, 2010 in Internet Business :: Social Collaboration Tools / Wikinomics :: Web | Comments (0) | TrackBacks (0)

Nobody cares about browsers

A lot of people seemed to be shocked that Google is advertising for their browser, Chrome. Even in the small town I live in (Spijkenisse) there is a multitude of bill boards which are promoting Google Chrome. However this is the only way to gain market share in a market in which people don't care about your product. People use the 'Internet-thing' that is pre installed on their desktop and why would they switch, since the browser experience will be the same.

A friend of mine helped his mom switching to Firefox (about six years ago). He made it simple for her by putting two icons on her desktop one named 'Proper Internet'  (launching the Firefox web browser) and the other one was named 'Internet' (launching Internet Explorer for sites that couldn't be rendered properly in Firefox). He didn't do this because his mother wanted to change, but because he loved Firefox so much. His mother did not care, she had Proper Internet and Internet en she even did not notice the difference.

It is almost like buying a new car. Most people buy a new car because they have to and some because they want to. Some of the buyers care a lot about brand others care more about color or certain functionality and others don't care at all, as long as it helps them to go from location A to location B and it is not too expensive. Most people care in the same way about browsers and most people don't care at all. So if you don't tell the no-carers that there is a different browser that could enhance their experience (Chrome is all about speed), they won't switch, since what they have is good enough (every browser they have is free, renders 98% of the websites correct, renders 100% of the websites good enough and helps them in visiting the things they want).

If you want to build market share you either build a very good product and trust word of mouth marketing, however if you have plenty of cash (as Google has) you can do a bit extra and involve more traditional media such as billboards and traditional advertisting in papers. And in a world where hardly anybody knows what a browser is, word of mouth is not so effective.

I wonder how Google will solve this issue with Chrome OS, since operating systems are becoming the same kind of commodity as browsers already are. They'll figure out, don't you think?

Rick Mans is a social media evangelist within Capgemini. You can follow and connect with him via Twitter or Delicious

Digg this Digg this | Seed Newsvine Seed Newsvine | | Posted by Rick Mans on February 5, 2010 in The You Experience :: Web | Comments (2) | TrackBacks (0)

New smart use case stereotypes for service oriented architecture

Smart use cases are a great technique for specifying standardized requirements in many types of projects. Over the past few years we have smart use cases being modeled and written in projects using Java and .NET, as you might expect, but also in Sharepoint projects, business intelligence, service oriented projects and even SAP implementations.

Stereotypes drive standardization
Standardization of your requirements can be an important driver to simplify software development and software rejuvination projects. An important addition to the smart use case modeling technique is the use of smart use case stereotypes.

These stereotypes represent often occurring patterns of requirements. Well known our the stereotypes manage, that represents a maintenance use case on some domain object, or search, which helps users to find a particular domain object, guided by search criteria. Other known stereotypes include select, master-detail, view, and report. As you might expect, these stereotypes all deal with user interaction.

Over the years however, we have gathered quite a few stereotypes, also in other fields. We have described for instance stereotypes that deal with Extraction Transformation Load (ETL) processes in data warehousing projects, such as aggregate, calculate and load.

Stereotypes not only help to put focus in modeling workshops, they also facilitate more easy project estimates, and even allow for straightforward code generation and isolated testing. Even better, once you marked the stereotypes (and put them into a UML profile), it will allow you to create much richer use case diagrams, modeling in colour.

IMAG0505
Modeling in colour using (profiled) smart use case stereotypes

Slicing service oriented projects
More recently we have applied smart use cases to service oriented projects. These projects tend to be more complex than regular software development projects, and focus around more elaborate architectures Service oriented projects mostly include:

  • Flexible front-end features. These can be either web pages, mobile phone front ends, Windows native applications or even Flash or Silverlight applications.
  • Process-oriented middleware. Service oriented processes always implement business processes. These business processes or workflows are run in middleware, more specifically in an enterprise service bus (ESB), although having such a bus is not mandatory. There are many vendors supplying busses, such as IBM, SAP, Oracle and Microsoft.
  • Stable services. A very important part of service oriented projects consists of the discovery and realization of services. Most often these services are implemented on top of existing legacy or packaged systems.

These slices in service oriented project all serve particular means and responsibilities. The approach to modeling smart use cases in such projects offers quite a few benefits. Next to modeling the front-end use cases, smart use cases help to model the business processes, and discover the required services.

Stereotypes for service oriented projects
In recent projects, that involved such complex service oriented architectures, we have gained a lot of experience in identifying and modeling smart use cases. This week we have analized a number of such models from different projects. This results in a set of new smart use case stereotypes, specifically targeted at the processes that run in middleware, and the encapsulation and execution of services.

IMAG0506
One of the smart use case diagrams we’ve investigated

Next to our well-known front end smart use case stereotypes, the new service oriented stereotypes include the following: process, aggregate, dispatch, validate, read, write and inform. I will elaborate on these stereotypes in the next sections.

Stereotype process
A use case of stereotype process executes a business process. In most cases it delegates the execution of services to other use cases, often of types aggregate and dispatch.

The process use case is in the lead, and uses the post-conditions from called use cases to steer the process. This type of smart use cases is generally implemented in the enterprise service bus, such as BizTalk or SAP Xi.

Stereotype aggregate
An aggregate typed smart use cases generally is used to create a single response to a request.

The stereotype is called aggregate as these use cases trigger other smart use cases, othen of types dispatch and read, and aggregates the results from these use cases into a singel response.
Stereotype dispatch

Smart use cases of type dispatch are intended to link the aggregate or process types use cases to services that either require some mapping, or typically run outside the organization.

Mapping is often required, as the available services do not always deliver what is required by the calling use cases. The dipatch smart use cases performs the mapping (hence and forth) and relays the work to the actual service, that is often of type read or write.

Stereotype validate
Executing business processes often include specific validation services, for instance to see if an customer is allowed to add a particular product to their subscription (as in one of the projects we investigated). Smart use cases labeled with the validate stereotypes return a single answer, that can be either a yes or no response, or a single value from a limited list of possible codes.

In cases of more complex validation, for instance when match-making between different back-end or external systems is required, the validate use case relays fetching the required information to dispatch, read or even aggregate smart use cases.

Stereotype read
Smart use cases with the read stereotype are the most basic services. Here one or more domain objects or entities are returned from a back-end system. This often includes compressing a whole hierarchy (such as with many SAP systems), such as a product hierarchy into a single returning message.

Stereotype write
In reverse, write typed smart use cases will pick up such a compressed hierarchy that is input to the use case, distribute the hierarchy into the back-end systems and persist it.

Stereotype inform
During the execution of a business process, the actual user of the whole process (being the actor of the user goal level use case initiating the process) needs to be informed of the status. The actor might get an email, such as in a subscription process to acknowledge successful subscribing, or be sent a letter. Other alternatives are of course also possible.

The inform use case is responsible for merging the text of the message being sent with the actual domain objects the use case model evolves around.

Sander Hoogendoorn
Principal Technology Officer Capgemini
www.sanderhoogendoorn.com
www.smartusecase.com

Digg this Digg this | Seed Newsvine Seed Newsvine | | Posted by Sander Hoogendoorn on February 4, 2010 in Agile :: Documentation :: Enterprise Architecture :: Scrum :: Smart use cases :: Software architecture :: UML | Comments (0) | TrackBacks (0)

Afterall Social Media is about... being Social

Recently I came across Social Media #FAIL Indian Software Companies from the NASSCOM India Leadership Blog and once again it’s highlighting an extremely important aspect of Social Media – of being social. Of course the article was focusing on the Indian market scenario particularly around Indian IT industry, but having said that, I think we can safely assume that we have seen a similar pattern across industries and geographies.

With the advent of a host of social media sites and the topic shooting to popularity, most people and organizations seem to feel that by having, just a presence on social media sites, one can sit back and reap its benefits. When in reality just by creating a twitter profile or searching for candidate profiles on LinkedIn may not bring them the returns on social technologies. It surely is the first step in the right direction, but assuming that one could see startling results with just that, will be foolish. As we say 'What goes around comes around' - expect very little returns (or responses) from the social technologies if you are not willing to share or participate. It’s time we realize social media is about being social – contribution, conversation, interaction, engagement (and the likes) with your employees, customers, or partners is what will bring benefits and remember the social technologies are only the enablers!

Another point the above article also brings out (and I am glad) is that, it’s not about using the most "hyped" social media site and more so - one size definitely doesn't fit all. Each tool has a specific objective of existence and though they seem user-friendly & popular, understanding their application in real-life business scenarios is equally difficult & important. There is a lot that goes into, before one starts implementing and using these tools. It really isn't another dot-com-bubble-kinds (that will go bust) that we are seeing so many strategy/consulting firms trying to help organizations in understanding how they can leverage from social media. Basics like knowing your pain-points, finding the best fit solution and customizing it to solve your real-life problem is the real deal. We really need to have a methodology / framework that will help in solving the business issues using social technologies, be it internal employee collaboration, interacting with customers or maintaining relationship with business partners. We all know this is still a fairly new playground for most of us (consulting firms & their prospective clients) and that makes it all the more important to have the fundamentals set right because each of us have a role to play. This just re-emphasizes the huge potential and opportunity for social business consulting & strategy practice and particularly the need for a formal approach and framework guiding social business engagements has, in today's world.

So, in conclusion - we just have to get social, in the real sense!

Nikhil Nulkar is a knowledge management consultant within Capgemini and is passionate about web2.0, specifically in enterprise2.0 & social media. Want to know what he is up to? Follow him on Twitter

Digg this Digg this | Seed Newsvine Seed Newsvine | | Posted by Nikhil Nulkar on February 4, 2010 in Nikhil Nulkar :: Social Collaboration Tools / Wikinomics | Comments (0) | TrackBacks (0)

Star Wars and Social CRM – use the Force

The other day I was trying to explain to a client what social CRM was all about and what the difference was to the first generation of CRM. Knowing the client was a film-fanatic, I used a Star Wars analogy.

Despite the best of intentions first generation CRM systems were about technology-enabled command and control. Think of the Original Star Wars film, Darth Vader and the Death Star. As Supreme Commander of the Galactic Empire, Vader built the original Death Star to defeat rebel forces in the Galactic civil war. The Death Star was a monumental technological feat designed to control the Empire and attack the Rebels. Relating this to the first generation of CRM (the boom before the bust)

• First generation CRM systems were technology-centric monoliths
• They aimed to own and control all customer data and customer facing processes
• Marketers used this data to segment and bombard customers with spam
• Sales managers used this data to control sales reps
• Customer service managers used CRM to standardise and micro-manage agents

The first generation of CRM put powerful tools into dangerous hands resulting in many failed CRM initiatives and the CRM market going into the doldrums for several years (I likened this period to the start of "The Empire Strikes Back", when Darth Vader and the Galactic Empire had driven the Rebel Alliance into hiding on the remote ice planet Hoth.)

During the early years CRM had a fairly high failure rate (some analysts estimated 60-70%). Those projects that did succeed were small, agile and focussed on outcomes (like the x-Wing Falcons that attacked the first Death Star at the end of "Star Wars"… I realise I'm jumping around the Star Wars trilogy a little but bear with me!). The successful projects paid a great deal of attention to the customer experience, front line staff, incentives and culture. Typically they broke down the CRM vision into small digestible chunks and built incrementally.

Over time CRM bounced back. The industry made a mental shift from "Inside-Out" to "Outside-In", putting the customer back at the rightful heart of CRM programs and learning from previous failures (big-bang approaches, poorly aligned culture and incentives, lack of exec commitment etc). The industry woke up and started to get CRM right and companies started to reap tangible rewards for their investments. In "The Empire Strikes Back", Luke Skywalker's awakening began at Dagobah where Yoda introduced him to The Force an "omnipresent form of energy which can be harnessed by those with that ability…an energy field created by all living things that surrounds us, penetrates us and binds the galaxy together". The Force allows users to perform a variety of supernatural feats and can amplify certain physical traits.

Relating this to Social CRM, the Force is the sum of all customer comments, feedback, blogs, tweets, yelps, diggs and sentiment. Some organisations are able to tap into this using direct customer feedback to improve products and processes, drive customer word of mouth for marketing and customer collaboration for service. Those who do this well are able to achieve amazing feats - see my post on outsourcing your Marketing, Sales and Service to your customers. Social CRM is therefore a natural extension of CRM. It further energises the return of CRM by placing the customer not just in the centre but now in control of the conversation.

So when we get to "The Return of the Jedi", the final film in the original trilogy, Luke Skywalker is now a fully fledged Jedi Knight, the Ewoks lead the rebel fight and Lando Calrissian launches a final assault on the Death Star in the Millennium Falcon. In an ideal world, that would be the death of technology-centric, command and control CRM (the Rebel alliance would celebrate the fall of the Empire) , but I suspect things aren't quite that simple. The battle is far from won. The Force can be used for both good (Jedis) and evil (Siths). It amplifies the things that an organisation does well along with the things they do badly (see my post on 10 angry customer created sites and campaigns).

Some people think visually so here's a link to my Prezi describing the above story. Enjoy and please let me know any feedback!

Laurence Buchanan leads CRM within Capgemini's Technology Services business in the UK. Follow him on Twitter or connect on Linkedin. This post was first published on www.thecustomerevolution.com

Digg this Digg this | Seed Newsvine Seed Newsvine | | Posted by Laurence Buchanan on February 2, 2010 in Social CRM | Comments (0) | TrackBacks (0)

Using Gravity to collaborate on processes in Google Wave just made SAP a whole lot sexier

By Maarten Engels and Niels van der Zeyst.

What is Gravity?
Google Wave has been around for a few months now and though the hype is fading away we are seeing more and more practical use-cases in the enterprise. One excellent example is SAP's Business Process Modelling tool gone collaborative; Gravity. We have been fortunate to work with a prototype version of Gravity with access to the minds behind the concept. Gravity is a Business Process Modeling tool which can be accessed as a gadget in the Google Wave client. This integration in Google Wave allows for collaboration over time and / or near real time, on business processes. This model is exportable to Netweaver BPM via BPMN 2.0 XML, thus making it a fully integrable modelling tool for use in an SAP landscape. Still puzzled? check this video with an explanatory example:

Gravity is a proofing point for Google Wave usefullness for enterprise scenario's; it boosts Google Wave’s "corporate credibility".

What are we using Gravity for?
We are using Gravity to model user interaction and flow in an iPhone application within a demonstration scenario for SAP and REST.

To demonstrate the value of REST in combination with SAP, we are developing an iPhone app that helps consumers search for recipies and subsequently translate the recipie into actual products available in the supermarket of their choice. In particular, this translation takes food allergies into consideration. We use REST to obtain ingredients, product data and allergy information from SAP.

The advantage to consumers is an almost instant overview of what products should be bought to cook a recipy based on food allergy and the actual products available in the supermarket. Based on a cross reference of personal profiles containing info. on Hypo allergenics (?) and PIM data from SAP.

Gravity helps us quickly model the steps taken by system and end-users to use our application. In particular, the collaboration features help out our cross-displinary team work from different locations and with different time schedules.

Our experience
Prototype alert: many features are still unimplemented such as selecting multiple objects, changing connections, annotating selects, etc. However, we are very enthousiastic in our first conclusions from working with Gravity:

  • Gravity is very intuitive and easy to use, the wysiwig and drag and drop interface combined with a no frills approach allows users to hit the ground running;
  • Integration in Google Wave helps to not only document the results but also the decision and brianstorm processes because history and context is retained within the Wave;
  • Collaborative editing works quite well both over time and distance and updates can be traced live allowing for immediate feedback and thus real-time collaboration;


Opportunities for value and growth
From our point of view, at this time Gravity seems most suited for high level process discussions with the client or within teams in earlier stages of process driven projects. Gravity fits in the SAP strategy for BPX and gives process owners, consultants and experts a tool to collaborate around, brainstorm on, explain and present process related activities.

Gravity seems extremely well suited for Geographically spread organisations. Collaboration across time-zones as is often the case with the global increase of outsourced and licesned work or projects.

The benefit of a Google Wave is that it is not limitied by access to corporate systems and firewalls for collaboration. However, If need be an export to Netweaver BPM is possible from where BPM experts can pick up and implement in the wider SAP landscape.

Gravity in a Wave allows for excellent documentation of the decisioning and ideation process and the discussions around it. The non-technical and functional documentation of a project that at times is vitally important but unfortunately often lost.

Conclusion:
It's not done yet, many basic features and nice extras still need to be implemented. However, Gravity provides us with a glimpse of what collaborative discussion and modelling could be like in a hybrid Service oriented landscape mixing Cloud based and proprietary architectures. We are very confident that SAP will be able to implement typical editing options such as multiple select, better support for drag and drop etc. And hope for more support of typical modeling methodologies such as UML.

On that note, if other model types would be implemented. Which UML models would you like to work with in Gravity?

Niels van der Zeyst is a Business Technologist at Capgemini. You can follow Niels on Twitter http://twitter.com/zeyst or contact him directly via niels.vander.zeyst@capgemini.com.

Maarten Engels is Managing Consultant at Capgemini where he is the leader of the SAP Infrastructure and Architecture profession group.

Digg this Digg this | Seed Newsvine Seed Newsvine | | Posted by Niels van der Zeyst on February 1, 2010 | Comments (2) | TrackBacks (0)

Weekly digest of week 4 2010

This week in the weekly digest: is Google twisting the knife in IE6, what about Constellation (SAP’s answer to Google Wave), and what about HTML5 and video what are the consequences of this? And were you aware that we spend more than 82% more time on social media than we did last year?

Light reading:

Rick Mans is a social media evangelist within Capgemini. You can follow and connect with him via Twitter or Delicious

Digg this Digg this | Seed Newsvine Seed Newsvine | | Posted by Rick Mans on February 1, 2010 in Social Collaboration Tools / Wikinomics | Comments (0) | TrackBacks (0)

Cloud and Social: the tectonic plates of IT 2.0

Tectonic_plate_boundaries.png

We're on the verge of a new era in IT. Web 2.0, E2.0, SOA 2.0: anything 2.0, which I combinedly call IT 2.0

My first IT experiences dating back 25 years, I've noticed that it basically provides humans with machines. Or more accurately, human tasks are slowly replaced by machine tasks where possible

It takes time to turn human tasks into machine tasks, so basically they shouldn't change while being built. They also shouldn't change much after being built. That's why building houses on sand was considered foolish millennia ago already.
It's almost exactly like portrait painting. It's a lot easier doing that when the model sits still, and when done the result looks much more alike if the model doesn't change too much after that

Knowing the how, now the question is: which human tasks can be replaced by machines, or automated?

The closer you come to business, the more humans you'll need. The further you move away from business, the more machines you can use. Basically, business needs people, and machine needs infrastructure

That puts humans on top in the IT foodchain, and machines at the bottom. Although arguably both depend on one another and couldn't live without...

Having said that, there are lots of different properties for humans and machines. Here's a quick model:

Machines serve automation. They are (and must be) rigid, because what runs directly on top is simple and static: great for storing business rules, they handle data very well. They sit in the infrastructure layer
Humans serve people. They are (and must be) flexible, because what they support is complex and dynamic: great for handling business exceptions, they handle information very well. They are part of the business layer

If you compare that to the latest trends, machines perfectly translate to Cloud, and humans to Social

IaaS, Paas and Saas all perfectly fit into the infrastructure layer mentioned above thanks to virtualisation and Utility Computing.
What can be xaaS-ed will be done so in the coming years, and albeit a relatively small slice of the enterprise layer, a large part of its current infrastructure will simply move into the cloud.
And in the years after that, a larger part of the enterprise will become infrastructure, and follow along: Invisible Infostructure is becoming an ever-increasing fact
The enterprise will become more standardised and simple at the bottom, and shrink

Social is 100% people-stuff and fits perfectly into the business layer. Communication (Blogs, Microblogging, Social networking) and Collaboration (Wikis, Social bookmarking, Social news) are tools that need to be plugged into the enterprise. Tools will come and go, be added onto, expanded, shrunk, and the people using them will move along. Process-on-the-fly is here to stay
Organisationally, culturally, politically a lot will change and it will keep changing before more than half of that becomes absorbed by the enterprise, and settles down.
The enterprise will become more complex at the top, and expand

Sketching the future, one can see the structure of IT 2.0 being sandwiched: at the bottom, the floor of the building will slowly be Clouded, while at the same time its ceiling will be Socialised. Two giant movements in opposite directions, much like tectonic plates operate on this earth's crust

Where will the twain meet? What will be there? Will that be crushed, or torn apart?
What will the consequences be for Enterprise IT as we know it, but especially for the future we have in mind for it: E2.0, SOA 2.0, SocialCRM?

I'm looking forward to your answers and ideas! I do foresee quite a challenge

Martijn Linssen is Enterprise Integration Architect within Capgemini. You can find him at martijnlinssen.com

Digg this Digg this | Seed Newsvine Seed Newsvine | | Posted by Martijn Linssen on January 31, 2010 in Enterprise Architecture :: Invisible Infostructure :: Process-on-the-fly :: Social Collaboration Tools / Wikinomics | Comments (0) | TrackBacks (0)



Subscribe


Recent Posts


Navigate



Search the blog