Welcome to MSDN Blogs Sign in | Join | Help

I have always believed that the front office is the sweet spot for the cloud - for now, and for a while - and recently I had the pleasure and privilege of collaborating with my friends at Sogeti on a book that - here is the blurb -

Improving Collaboration between people and between organizations is no longer optional if you want to survive in today s hyper connected business world. Speed of change, unpredictability and the increasingly social nature of the marketplace make collaboration instrumental to your company s ability to differentiate. New ways of collaboration are starting to take place within your company, across value chains and in the individual social domain of your employees. At the same time, new architecture and delivery models are bringing many new collaborative tools within reach of every person in your organization, with or without your knowledge or control. The use of personal email is one example we have learned to address, but how do you respond to personal workspaces, document sharing or instant messaging? Or even better: how does your business benefit from them? On the technology side, a volatile mix of acronyms like SOA Service Oriented Architecture, SaaS Software as a Service and Web2.0 is brewing that is drastically changing our view on the role and value of Information Technology. If left to chance there is little hope for success: you need a strategy. The new business world that is starting to show all around us is driven by autonomous, bottom up organizations where innovation and collaboration are part of the culture. In Value Chain 2.0, it is about quickly establishing combinations that offer value to the marketplace. It is about crossing boundaries and taking the full benefits from Cloud Computing and anything available As A Service, from platform to complete business solution. 

Erik Van Ommeren is one of the smartest people that I have had the opportunity to work and collaborate with - his passion for emerging technologies and their application to business is remarkable. I really enjoyed working with him and the team on this effort - and I hope that you find some value in this book. There is also a web site where you can find additional information.

Almost two years ago I had blogged about what I called the 'my cloud' pattern. Lately, this has been getting a lot of buzz amongst the analysts and in the blogosphere.

Whilst I still believe that this a real pattern - I am concerned that the marketing is now getting ahead of the technology.

 It is also not clear to me that this is a mainstream opportunity. I think the likes of the DoD and NHS will probably go down this path - but if you are a mainstream enterprise customer, then it is probably worth asking yourself - what is the problem that I am trying to solve? and make sure that you understand how this maps to the putative offering.

I have had the opportunity to work very closely with the patterns & practices team over the years. We have collaborated on the Composite Application Block (which was incubated in my team many years back), on Web Services patterms, on the Smart Client Architecture Guide (a blast from the past :-)) and more... I have had a great deal of respect for the team, the people, and their ability to take on challenging problems, across diverse domains and deliver.

so, it was a privilege and a pleasure to be asked to take on the role of leading the team.

There are some amazing people in the team, the passion is contagious and something to be seen to be believed - and there few places if any inside Microsoft, or any other company for that matter, that give you the opportunities to work in this area.

I am very excited. And looking forward to this journey.

ps Glenn I did eventually blog this :-)

There is a recurring pattern that I am seeing in the large enterprise space that I think of as the 'my cloud' pattern.

Essentially, large enterprise organizations that are interested in the business and technology model advantages of moving to a software + services model, but are asking their IT organization to become a service provider, as opposed to out sourcing their IT portfolio to the sky.

 

 

It is often (implicitly) assumed by many that BPM comes after SOA.

The challenge, even with little BPM, is that the focus is primarily on optimization, not on innovation. It is almost always about the 'boxed-in process' - and about drilling down - less about stepping back and out. Paving the cow-paths has its pros and cons as you can imagine - but there are few if any that would argue that paving the cow-paths is the path to innovation...

anyway, this thread was spurred by some discussions recently on what is the next big thing...

It would appear that OpenSocial and SCA are birds of a feather –

 

1)       A singular focus on portability (components or widgets) across containers

2)       Disregard for data and data integration

3)       Sound bites about value for the end customer when it is really a provider (or ISV) play for relevance

4)       Reactive response to the dominance of a vendor/technology (Facebook or .NET as the case may be)

 

when in reality what the end customer/user wants is interoperability and unlocking/sharing of data, across heterogeneous systems and social graphs, as the case may be.

Is it 'management' when you sell to the technical decision maker - and 'governance' when you sell to the business decision maker?

I know I am being cynical here. But I see too many web services management vendors that now call themselves soa governance vendors.

I absolutely understand the pain and the need for governance. But it has always been and it is still about the people and processes 

Vendors cant sell governance - nor can customers buy governance.

Governance is hard work. It requires driving cultural change across the organization. There is no short cut to success here.

 

Joe's column is one I have been following religiously for a while - a must read if you at are interested in SOA.

His write-up on how we think about SOA really nails the core of our philosophy. Just do it!

 

well, I am out today with a virus and am coughing my way to the doctor - but that is a different story.

We talk about 'discovery' in SOA, cough, cough. I have been working with customers on SOA for over 7 years now - and I must confess that I haven't seen enough of discovery to beat the drum on this.

Do you have real-world evidence/case studies to highlight this in your work? Please drop me a note if you do.

Following up on my post from last year http://blogs.msdn.com/jdevados/archive/2006/08/02/687269.aspx - I think there is a similar distiction that we can make for BPM.

Alex Moulas nails it in his column http://www.bpm.com/FeatureRO.asp - "A large, progressive company wants to be a more processed-focused enterprise. Best practice dictates combining business analysts with consultants from a major system integration firm to detail architecture and interview employees to capture the real business process. Plans are developed, and with methodologies in hand, significant initial progress is made. As weeks and months progress, more time is spent managing documents, drawing and re-drawing process maps, reviewing, correcting, checking interdependencies and trying to ensure consistency and uniformity. After 11 months, the combined teams are disbanded and no actions or conclusions are reached. Budgets exceed planned expenditures and frustration prevails. Ultimately, the entire project is put on the back burner or …

This is a typical “best practice labeled” engagement that will more often than not fail. Not because of poor planning, resource allocation or budget constraints, but because of a typical and traditional “top-down,” macro-view analysis" "

This is big BPM.

What he calls Business Process Discovery is what I think of as the real-world, emergent approach - what we could think of as little BPM. Driven by the community - "capturing the business process as it exists and is exercised daily in the enterprise, by users on IT systems. " - very well said Alex.

http://www.codeplex.com/TFSGuide - a must read.
I was in a discussion with a customer this morning - and the topic of UML came up. I think Martin Fowler nailed it with this masterful post from a couple of years back.
http://www.bpm.com/BriefingRO.asp?BriefingId=31 is an excellent commentary on the state of the BPM space.

recently, I was in an email thread where we had someone ask about dependency on XYZ.

I think this is an area, where much like the conservation of energy, you can shift the dependencies around - language, tool, framework, operating system, vendor, systems integrator, hoster etc - but at the end of the day you still have dependencies.

You are better off when you are aware of the dependencies - the unknown dependencies are the ones that are going to be expensive to deal with. I would recommend investing on a real options analysis if you are looking to add some rigor to your dependency analysis - just be aware that there your solution always has dependencies.

 

 

Harry has been asking me when I am going to start blogging again - thanks for pushing me Harry.

He talks about my big SOA, little SOA post from a long time back - it seems that the nomenclature has taken on a life of its own now - I saw Joe McKendrick refer to this recently as well.

Yeah - how do you eat an elephant again? one bit at a time - yes, we are on the same page.

We have been through this before - http://www.microsoft.com/presspass/features/2006/oct06/10-04SOA.mspx

1.

Make sure that you have sound business drivers. Oftentimes we see customers struggle to justify their SOA projects – it is almost always because they are trying to "do SOA" as opposed to addressing a business need.

 

2.

Top-down, big-bang mega approaches do not work in the real-world. Bottom-up approaches are not manageable. But there is an approach that we see successful customers adopt – what we call the middle-out approach. These customers all have something in common--they start with clear business challenges and focus on creating business value

 

3.

Try to avoid subscribing to what I call "the build it and they will come" approach. They spend 18 months to 30 months building a services infrastructure, and eventually, when they reach the service consumption layer or what is called the user-experience layer, they find that the business has moved on. That what they have built is something that made sense for the business at a point in time in the past, but by the time their solution was ready for prime-time, their business needs had changed and their investments were all for none. We recommend customers partition their use cases into small sets and build out the entire use case end-to-end, from the data through to the consumption. You don’t learn by planning – you learn by doing. Partitioning your functionality helps you track changing business needs much more effectively.

 

4.

Demonstrate value in rapid iterations. Time-to-value is a critical metric, a healthy metric. The trust-me approach is not a healthy model for customers that want to be successful leveraging SOA.

 

5.

Last, but not the least, successful customers use what we call a "snowball" approach. How do you build a big snowball? You start with a small snowball. This is probably the most important take away with respect to leveraging SOA to drive business value.

 

More Posts Next page »
 
Page view tracker