It seems like there are still too many variations in terms of what SOA is and what it means to people and that we still struggle to describe it to a broader audience.

To me, SOA is all about the convergence of Mindset, Methodologies and Technologies.

• Mindset because SOA is all about thinking in services and not in technology
• Methodology because it is a pattern and style on how to structure systems, applications and processes supported through architecture and implemented by people
• Technology obviously supports and ultimately allows us to implement the latter two in an integrated fashion

But the true difference is about the convergence of these three that makes the up SOA !

I spoke to a company today in exactly that situation. Their primary backed had to recoup his investment for other purposes directly because of the credit crisis. Siutations like this should be opportunities for cash rich firms and should lead to some interesting developments.

Have you got any guesses?

Surprisingly few people have been shy in requesting a copy - it seems that most people are “picking up a copy for their boss”!  Recently we met one such boss - Mr Ed N. Sand.

Ed is an effective COO, but like most COOs, is so busy with day-to-day work that he struggles to keep up with new developments.  We managed to get Ed to take some time out of his busy schedule and do a little bit of ‘reality TV’ for us.  You can see the results here.

Feel free to reach out to Ed with your questions, your advice or your sympathy!

WOA is a very fast paced “Web 2.0-ish” way to innovate and mash up concepts quickly. And the massive power of it is that you are standing on the shoulders of Giants who have built “Social Utilities” and amazing Web-Oriented APIs so that you can use astonishingly simple expressions and get vasty goodness (technical term) very easily.

The article states…

WOA has evolved via massive scale trial-and-error, and so has been designed through viral adoption, user pull, self-help and with self-qualification of real-time productivity in mind. It works because it just works, not because it’s supposed to work, or because someday it will work. As Dion says, “And these new models intrinsically take advantage of the important properties of the Web that have made it the most successful network in history.”

It really is a phenomenal quick start to value and a great way to interconnect people to one another. This is a way to extend brand, compete, offer new applications, listen to events on the network, offer compelling new user experiences, participate in “long tail” economics, and just plain try out a million things cheaply.

In fact, the key idea of letting a thousand or million flowers bloom on the “platform” and let nature select the winners was the theme of my SOA World Keynote.

The interesting challenge for the Enterprise is how can the core components that generate the majority of revenue for the enterprise be successfully deployed as a platform? It’s one thing to take advantage of everyone else’s platform out on the internet and it’s a completely different thing to offer platform services of your own.

The experience of being a consumer of services is very snappy and cool and you can use this WOA experience to show value quickly and mash up some amazing things. You can leverage the massive power (and in many cases free hosting, viral application distribution, and software services) of Web Oriented platforms that are offered and for the most part freely available to anyone with markup skills and maybe a scripting language like Ruby Python PHP and JavaScript.

So go kick some butt on WOA. It will do you a world of good. But keep in mind that having something of value to offer the Internet and distributing those services (whether freely or not) enables you to add value to your customers and your entire value ecosystem. By offering your own business services on the network, you can encourage all of the innovation in your ecosystem to build on top of *your* enterprise platform in a wild and open way… and let the laws of nature select which ones will be successful for you.

This will give you the “Peacock’s tail”, which is sort of a tail made up of a lot of tail feathers. You’ll find that having many many customers and many many different ways to serve them is going to make your offerings compelling, sticky and value adding.

My 2 cents,

Miko

As the main contributor and moderator of Modern(ized) Insights, I think you should know a bit about me – Sandra Wade.  I’m the Senior Director of Product Marketing for Software AG’s Enterprise Transaction Systems business line and am responsible for, among other things, the positioning of our webMethods Application Modernization Suite in the market. I haven’t always been involved on the mainframe side of things.  No, like many others that graduated with a degree in Computer Science back in the early 1980’s, I set my sights on all the hot, new technology.  I focused on distributed operating systems, client/server architectures, C++ programming (oooh), and extended relational and object-oriented databases.  I was even my company’s representative on the Object Management Group and Object Database Management Group.

BTW - check out patent number 5826268 granted October 20, 1998 if you want to see how I spent nights and weekends back in the day; I was co-author on the patent covering Secure Multilevel Object-oriented Database Management System. Funny thing is that after spending 13 years becoming an expert on all the “fun” stuff, I ended up with the responsibility of defining, developing, and launching INTERSOLV’s Year 2000 solution suite to market. Needless to say, I had a lot to learn - about mainframes, COBOL and other “legacy” programming languages, Y2K remediation techniques, etc.  That’s when I got the huge wakeup call that all those systems I dodged when I graduated from college were actually THE systems running the bulk of transactions supporting major financial, government, insurance, manufacturing, telecommunications, and yes - even higher education industries.

You’d think that 20 years later all the systems that need to be modernized would have been modernized by now - right?  So, why haven’t they? Are these projects viewed as too costly?  Too risky?  Are people of the opinion that the systems should be replaced with off-the-shelf package applications or re-written from the ground up?  Are the systems “good enough” and therefore not worthy of  modernization?  Do organizations lack the skills to move systems forward? I’d like to hear your thoughts on all of these topics. So get involved and share some of your own Moder(nized) Insights!

But first, what’s SaaS?  Gartner provides a definition that mentions “software that is owned, delivered and managed remotely by one or more providers (and that) delivers an application based on a set of common codes and data definitions that are consumed in a one-to-many model by all contracted customers anytime.”  Let me sum that up for you: SaaS is all about cost savings.  And cost savings are great, but if the enterprise software industry is betting on delivering value largely by cutting costs I need to find a new industry.  Clearly reducing costs is a major driver for automating anything, and a perfectly legitimate one.  What’s exciting, interesting and most promising for the software industry is figuring out how to enable the upside for our customers—how do we help them increase revenue?

The problem with SaaS is the same for traditionally delivered packaged apps like SAP’s—they deliver non-differentiated (implicit) business processes.  No company is going to grow revenue by doing a better job of paying an invoice or cutting a paycheck.  A business process that differentiates an organization and therefore offers the opportunity to beat the competition is the way to grow revenue. These (explicit) business processes cannot be delivered in the same way to every company in the world so they are not conducive to packaged applications where the same process is sold over and over again, whether they’re delivered on premises or via SaaS.  So maybe SaaS will save some money—but will it help you grow?  I don’t think so.

I’ll come back to this topic in my next posting—in the meantime, what do you think?  Can a packaged application really differentiate?  And does it matter if it’s on premises or not?

So what can enterprise IT learn from the concept of recycling? IT systems no longer just support the core processes of an organization. But rather they often form the most important parts of these processes. Organizations need to use the example of established industries to improve their internal processes with which IT solutions are created.

The challenge now is to define as many reusable software components as possible and to organize them in a clearly structured manner. These structures control the roles and responsibilities of the different components as well as their lifecycle process, including design, production and operation. The software components can vary in nature: Web services representing business logic, data structures, process definitions and, last but not least, policies such as security guidelines, access rights and service-level agreements.

Anyone who wants to efficiently manage so many components and use them to compose sensible solutions first needs clear descriptions and meta data. This enables all parties of an organization to understand what components can be used for specific situations and in what way they can be combined.

SOA governance addresses the issues of transparency and reusability. It defines clear organizational responsibilities for the interdependency of the components in an SOA architecture. For example, an employee could try to compose a new solution by combining an SAP BAPI, via a Web services interface, with other Web services representing mainframe logic. This could fail because the security concepts of the different services dictate that under certain circumstances they are not permitted to be combined with each other. Descriptions and meta data for the components have to be quickly accessible in order assemble systems using components – just as in the manufacturing industry. With this approach, the development effort, behavior of the finished application and the effort necessary for subsequent changes are all calculable in the design phase of the solution.

SOA governance addresses a fundamental task which is relevant not only to the advanced SOA implementer. It is an approach that enterprises should consider at the beginning of every project in order to guarantee the success of their SOA initiatives.

But the challenges and benefits of SOA are on an entirely different scale. The past shifts were like moving from the horse cart to automobiles. SOA is akin to moving from ground transportation to space flight. Compared to ground transportation, Space flight involves a whole new operating environment, with new rules, new opportunities and new dangers. As a result is requires an entirely different class of vehicle (the spaceship, you will agree, is quite different from even the most sophisticated car), processes (mission control) and personnel (astronauts). Similarly, SOA also requires a big shift in the technological approach to application development and operations. And it has a fundamental impact on IT people and processes. SOA calls for new roles, new ways of organizing people, new levels of collaboration with IT and between IT and business and a new need for visibility and accountability. Just as every space mission requires technology to align with people and processes - every successful SOA adoption initiative requires technology to support people and processes such that it creates positive momentum and desired level of control.

So, when building out infrastructure for SOA you will not only have to think about technical considerations, but you will have to pay equal or even more attention to how the infrastructure supports people and processes.

What does this mean in practice? Well, the right infrastructure is certainly needed for technical goals like enabling service consumers to find, and connect to service providers. It is needed to ensure interoperability among heterogeneous service providers and consumers. It is needed to ensure that services can scale to handle demand from multiple consumers. It is needed to ensure that security is not compromised even as systems are opened up and functionality is made easily available to other systems. But infrastructure is also needed for organizational issues like stability of the SOA as new services, providers and consumers enter the mix. Infrastructure is needed to gain visibility that will drive processes ranging from change management to tracking service level agreements to making investment decisions in building new IT capabilities and capacity.

The right infrastructure is needed to drive important organizational behavior like willingness to trust and reuse capabilities developed in other parts of the organization. Failing to provide these characteristics in your infrastructure can be quite detrimental to SOA success. Lack of any one of these characteristics is enough to bring SOA projects to a grinding halt because the consequences are not acceptable to consumers or providers or both. This can significantly slow down SOA adoption. Clearly, this is important stuff!

Is there still concern over Baby Boomer retirements?

Not so much.  I’m currently of the opinion that the concern organizations had early in the year regarding dwindling mainframe skills has gone by the wayside.  Many would be, up and coming retirees are putting off retirement.  The decision to do so is primarily driven by the huge losses suffered by pension and 401K plans in 2008.  Check out “Shaky Economy Puts Retirement Plans on Hold” in the AARP Bulletin Today.  While this is rather disappointing to those who have worked what seems like a lifetime, it offers a reprieve to organizations that have yet to put together a succession plan to ensure mission-critical systems continue to be supported by knowledgeable workers.

Are the people responsible for mainframe systems still unhappy with the term “legacy”?

I’d have to say the answer is a resounding “YES”.  Since I haven’t met anyone in IT that isn’t familiar with the Dilbert cartoons, I’ll simply point out the set of comic strips that kicked off on December 15, 2008 - http://dilbert.com/2008-12-15/.  I’m afraid that once again Scott Adams has hit on a corporate attitude that hits a bit too close to home for many of us.  Legacy definitely continues to be quite a derogatory term and is best eliminated from most IT-related conversations.

Is the “going green” movement still going strong?

Here, I’d have to say kind of.  The “going green” movement is still going strong, but has lost prominence in the media - being replaced with anxiety over the global economic crisis.  When organizations are focused on simply keeping their doors open for business, it’s a bit difficult to focus on being environmentally responsible.  Read “Tech layoffs: The scorecard” if you want to see just how hard the tech industry is being hit by the economic downturn.  Needless to say, I see the “going green” movement being placed on the back-burner as IT organizations shift focus to proving 2009 budget requests are clearly aligned with the business’ need to reduce costs while maintaining competitive advantage.

What’s in store for 2009?

That’s hard to say.  Guess I’ll spend the remainder of 2008 peering into my crystal ball.  I wouldn’t be surprised to find that IT will be under even more pressure to get additional value out of existing IT assets than in years past.