MomentumSI Blogs

Feeds

112 items in 3 feeds

• Service Oriented Enterprise
• Thank You Zaxxon
• MomentumSI at Gartner AADI 2008

Recent items

Service Oriented Enterprise

• 

  Linthicum on ESB's

  Posted: July 18th, 2008, 2:03pm CDT by jeff

  Several people have sent me the latest Linthicum article on the back channel. People are asking if I agree...
  
  [weblog.infoworld.com]
  
  Dave comments:
  

  First, if there is indeed "enterprise architecture" and an "enterprise architect" then the different divisions should not be using different ESBs, or even an ESB for that matter.

  
  
  Companies are buying ESB's, will continue to buy ESB's, will buy products that are packaged with ESB's and will acquire/merge with other companies that have ESB's. They aren't going away - so yes, large companies will have to figure out how to deal with having more than one...
  
  
  Dave moves on to his second point:
  

  Second, considering that my first point is correct (which it is), why the heck are you attempting to integrate these integration engines when they should perhaps be displaced altogether.

  
  
  In an overconfident, if not pompous manner, Dave declares himself correct. He then wants to know why a single dictator doesn't come in and end-of-life various products across business units, geographies and missions. Well, it might be a good idea for I.T. but may not be in the best interest of the business.
  
  Personally - I see this as just plain silly advice...but perhaps, I misunderstood his point.
• 

  Silo Analysis: Key to SOA Success

  Posted: July 10th, 2008, 11:13am CDT by jeff

  At virtually every conference I attend, I hear someone declare that we need to "destroy the silos", and that SOA is the enabler. Loosely, I think of a silo as a system or information repository that solves a problem for some portion of the enterprise, while leaving other areas responsible for solving the same or similar problems on their own. Silos causes duplication of systems, business rules and data. They require multiple levels of integration and cleansing, resulting in increased maintenance and operational expenses. In general, silos are bad.
  
  After working with a handful of organizations, it occurred to me that these companies had not performed "Silo Analysis". Almost every large organization has a number of silos that exist for a variety of reasons including:
  - I.T. funding occurred by business area and each area bought/built their own (silo) systems
  - Mergers or acquisitions caused duplicate (silo) systems
  - Poor visibility or planning across the enterprise led to unintentional silos
  
  
  
  The rumors that SOA can help are true. But before rushing down the path, organizations need to ask some important questions:
  - What are our silos?
  - Is there a good reason for the silos?
  - Which silos do we want to end-of-life?
  - Which silos can we practically kill (politics, investment, etc. )
  - Will SOA lead to "silo services"?
  
  Silo Identification
  The first step to this process is to identify what silos you currently have. As I mentioned earlier, silos often mimic organizational reporting and funding structures. Here are some easy ones to look for:
  - Corporate Sectors / Divisions / Business Units / Departments
  - Sales Centers (Asia, Europe, Americas, etc.)
  - Facilities (warehouses, manufacturing locations, distribution centers, etc.)
  - Delivery Channel (Web, kiosk, mobile, etc.)
  
  It is common for these structures to be embedded within each other as well. For instance, Acme Corporation might have duplicate CRM systems for each SBU, but also have additional CRM systems in the Asia locations of each SBU. In essence, the silo analysis has to look at combinations of the structures.
  
  Silo Justification
  Not all silos are bad. There are often good reasons why silos exist. Unique business requirements may require unique I.T. solutions. It is important to understand WHY the silo system exists but be careful not to let the 'unique business requirements' become a universal excuse for duplicate systems.
  
  Silo Targeting
  Once you've found silo systems which could be rationalized to a single service, you have to decide if their is political will power to "de-silo" the area. In many cases, if not most, it is very difficult to retire systems. The upfront cost of retiring a system is often a burden that an organization will attempt to defer for as long as possible, typically stating there are "higher priorities". The bottom line is that there will always be higher business priorities but I.T. must make the case for retiring the old.
  
  Often the goal isn't to retire the systems but merely to create a single point of entry. In such cases, I.T. can create front end interfaces that access multiple legacy systems which cross silos. Here, we aren't retiring systems, rather we're 'bridging the silos' by standardizing the access point allowing consumers to get a single view.
  
  Preventing Silo Services
  Service Orientation offers a great mechanism to decrease the number of silos and mitigate the damage of the silos which can not be eliminated. From a rationalization perspective, SOA offers the ability to create a single "Master Service" that acts as the single source of truth for logic AND data. However, many organizations are not realizing this vision. As many have noted, services continue to be built in an ad hoc fashion resulting in JBOWS (Just a Bunch of Web Services). In almost every case JBOWS are merely silo services that were created because no one funding authority had the charter to perform silo analysis and justify a non-silo solution.
  
  Although the 'governance' and 'cross-silo funding' problems are barriers, I believe a more tactical barrier remains. I.T. leaders are failing to teach their organizations about the silos. What are the silos? Why do they exist? Which ones are we chartered to knock down? Which will be tactically bridge? And when we do knock them down, how will we advertise that a service isn't a silo service, but rather a Master Service that crosses the divide? And perhaps most important, how do we prevent 'silo creep' in the future. Today, most software professionals have no concept of 'attaching' their unique business logic to existing services.
  
  The Bottom Line
  SOA offers a great solution to the silo problem but it will take significant political power to pull it off. Even if you are able to remove some of the silos, you'll need a plan to prevent unwanted new ones. Silo Analysis must be ingrained in the mind of every business analyst, architect, developer and governance professional. Failure to teach our next generation will lead to more silos - they'll just be written in Ruby instead of Java...
• 

  Mindreef acquired by Progress Software

  Posted: June 26th, 2008, 5:22pm CDT by jeff

  Wow - how did I miss this one??
  
  Mindreef was acquired by Progress Software!
  
  Quietly, Progress added another set of tools to their growing SOA portfolio. Through this acquisition, Progress picks up new SOA testing at quality management solutions. Congratulations to Frank Grossman the rest of the Mindreef team.
  
  And again, I've updated the SOA Acquisition List:
  [www.momentumsi.com]
• 

  Iona acquired by Progress

  Posted: June 26th, 2008, 3:42pm CDT by jeff

  Progress Software announced the acquisition of Iona.
  
  This move continues to round out their SOA offerings by adding registry/repository, data services, message brokering and CORBA middleware. However, as others have pointed out, this leaves Progress with significant overlap in the ESB area. I'm confident that we'll be hearing from the Progress leadership on how they intend to resolve the redundancies that exist between Artix, FUSE, SOAPStation and SonicESB.
  
  Naturally, here is the updated SOA Acquisition List.

Thank You Zaxxon

• 

  Gartner AADI 08 Orlando Wrap Up

  Posted: June 11th, 2008, 3:22pm CDT by Jason Henley

  Well the conference is winding down and I'm taking an SOA breather to
  reflect and exhale. Well I'm actually watching EURO 08 but I am
  reflecting.

  I have to say that all in all I enjoyed the conference. I especially
  enjoyed seeing and meeting the other members of our team. We stay
  pretty busy and unless we're together on a job we don't see each other
  often.

  I was pleased to see that many of the concepts, patterns and processes
  presented were not new to me and in fact were things that myself and
  the rest of the team already do and apply everyday. Of course there
  are always things to learn or new perspectives to discover. I met some
  nice folks and had fun in the unsanctioned events as well ;)