In my travels, I often run into two seemingly unrelated conversations that I view as two sides of the same coin.  There is one set of people that talk about how their existing systems, processes and people need to evolve – increasingly, these people are using the term “modernization”.  On the other hand are the people working on various aspects of SOA, Web/Internet, Agile Methododologies, SaaS, Cloud Computing, etc.  When I ask the first group what a ‘modern’ set of systems, processes and people/skills look like, they rattle off pretty much the same list as the second set of folks.

The big difference is that the second set of folks are often starting in newer areas – like their enterprise’s web sites – whereas, the modernization set of folks is starting with longer standing systems often built on things like mainframes, COBOL, etc.  The fact that people focused on modernization need to deal with the longer standing systems as part of getting to SOA, Web, Agile, Cloud, Saas – led us to create an entire track of sessions dedicated to modernization. 

Dale Vecchio is the lead analyst on modernization, which has been a significant research initiative for us for quite some time.  Make sure to check out Dale’s sessions on:

• When the Software Outlives the Developers: Market Forces Driving IT Modernization
• Can SOA Save Your Legacy Applications
• Analyst/User Roundtable: Legacy Modernization Through SOA
• Analyst/User Roundtable: Mainframe Migration – When and How to Do It?
• Case Study Panel: SOA as a Legacy Application Extension Strategy
• Case Study Panel: Mainframe Migrations – For Better or Worse

Open Source continues to increase as a force in the applications world.  Just as an example, it is fairly rare to find a development environment that doesn’t have eclipse present in some way.  Countless other Open Source projects have found their way into many of today’s homegrown and packaged applications.  Legal questions continue to be raised, which Mark Driver recently blogged about in Good Books On Open Source Legal Issues.  However,  Mark will cover two more important questions in the following sessions:

• The Role of Open Source in Modern SOAs
• When and How to Adopt Open Source Software (Analyst/User Roundtable)

I just read Nick Gall’s post WOA: Putting the Web Back in Web Services.  The whole notion of Web Oriented Architecture (WOA) is to leverage the basic web concepts from the Internet in SOA efforts.  Nick has provided excerpts of a great research note that lays out many of the fundamentals in this train of thought, including a basic definion and principles.  A great opportunity to hear about these concepts live and have them contrasted with other approaches to SOA is to attend The Great Debate: Should I Use Web Services or REST for My SOA?

One of the oldest adages about application success or failure is that it hinges on being closely aligned with the business.  Ironically, even though people have been saying this for decades, many organizations still fail at lining up closely with the business.  It seems that every new approach to applications gives us yet another chance to get this wrong – SOA is no different! (See Frank Kenney’s SOA Failure post)

I urge all of you to check out these two documents:

• Five Principles of SOA in Business and IT
• The Business Impact of SOA

You should also attend the Workshop on Business Alignment run by Andy Kyte and Susan Landry.  At the highest levels, business alignment implies that applications plans line up with business strategy.  Andy has a great take on this and the need for an application strategy in his session: If You Had an Application Strategy, What Would It Look Like?

November 6th I did an open to the public audio teleconference presentation on the subject topic. It was attended by about 200 of the people to whom we reached out. The slides are available in .pdf form at  http://www.gartnerinfo.com/aadi/slides.pdf.  Here is the link to the accompanying audio. I’ll update this post when we do. Any comments on the presentation are welcome.

This presentation also served as an overview or primer for the content we will deliver at the Application Architecture Development and Integration Summit in Las Vegas from Dec 8-10.

Application leaders continually bring up security as an ever increasing concern.  Unfortunately, most people don’t understand application security, confusing it with firewalls, intrusion detection systems, virtual private networks, SSL, and other infrastructure security technologies.

As Joseph Feiman so aptly puts in his Application Security in the SOA World Session, whilst these technologies are useful, they are “not sufficient for application protection.” He also points out that security is not a synonym for quality and that reusable components could be a source of reusable vulnerabilities. However, my favorite point that Joseph makes is that “you cannot secure what you don’t understand”.  To really get application security right, you need to dive into the actual application, its process flows and related data constructs. Joseph is also conducting an analyst user roundtable on Secure Application Development – What Works and What Doesn’t.

John Pescatore happend to write a post - Ten Years to Get Good, Ten Minutes to Prove It - inspired by a piece on Malcom Gladwell’s new book Outliers.  Since Malcolm happens to be giving one of the keynotes at the AADI Summit, it feels right to connect the dots a bit.

In his book, Malcolm highlights the 10,000 Hour Rule that says in order to excel at something you have to spend at least 20 hours a week for ten years doing it.  John builds on this and mentions: “I think for the first ten years of my career I was really good at attacking and solving problems, but not so good at seeing the connections between the problems, or any patterns that could lead to ways to avoid the problems.”

It strikes me that this is a bit similar to the challenge that many of us are facing in the next generation of application development, where the focus is less on creating new discrete pieces of code – the thing that many have spent the last 10+ years of our lives doing – and more about pulling together/assembling existing discrete pieces of code into larger ‘services’ – similar to John’s notion of seeing the connections between problems.  This ties back to my previous SOA Failure post, where I highlighted the application development community’s unhealthy fixation on re-creating the wheel rather than re-using good code from elsewhere.  Hopefully, many of you are now well into gaining 10,000 hours of experience around service oriented development and the related concepts of composition, orchestration and assembly.

Michael Blechar is leading a great set of sessions on this:

• Roadmap for Service-Oriented Development
• Analyst/User Roundtable – Best Practices in Service-Oriented Development
• Trends in Model-Driven Collaboration

In my travels, I continue to run into people that are just getting started with SOA.  If you’re in this camp, you should have a quick read of our SOA Overview.  Then check out the track of sessions dedicated to Initiating an SOA effort.

As Dan Sholler points out in the track keynote,  the key things to keep in mind are:

• The fundamentals of SOA are agreements
• The major opportunities for SOA are where agreements already exist
• Focus on projects that address clear business pain

I just read a PAINFULLY funny post by Frank Kenney called Ahh Shucks, SOA is a Failure.  He nails the top reasons why SOA initiatives fail and not so subtly points out that the person in charge of the initiative is far from blameless or powerless.  In addition to not lining up with key business neeeds, the other reason for failure that just KILLS me is “I failed to provide my developers incentives to reuse artifacts”.

We (the development community) have made this mistake countless times.  After all, weren’t we going to drive reuse through function calls, stored procedures, objects, etc.?  I can promise you that unless you do the following, you are leaving reuse to chance (at best):

• Provide a catalog or library of what should be reused
• Make sure things to be reused are of high quality
• Specify reuse in your methodology
• Incent project managers, developers, and buisness people to reuse things
• Measure whether reuse occurs
• Reward reuse when it occurs

Most of the failings of SOA can be attributed to failings in governance.  Check out Frank’s session on Governance of B2B Web Services in SOA and his Analyst User Roundtable on Best Practices in SOA Governance.  Also make sure to see SOA Horror Stories to hear a painfully entertaining view of major SOA-related mistakes and how to avoid them.

One of the most interesting new areas of research that I have seen is the work led by Bill Clark on Context Delivery Architecture. The notion is to have applications take into account the “context” of the user, such as their location or previous behaviors.
It made me think of a great little “flashmob” video of Grand Central Station. (Check this post for more on flashmobs) This is a great example of a change in context! Imagine the potential of taking into account information outside of the main process or transaction that someone is focused on…there is tremendous potential to bring new business value to the table. This becomes really interesting when combined with Event Driven Architecture concepts, which you can see in the Event Processing Scenario presented by Roy Schulte.