Enterprise Initiatives

This blog focuses on Enterprise IT topics such as Enterprise Architecture, Portfolio Management, Change Management, Business Process Management, and recaps various technology events and news.


Showing posts with label Zapthink. Show all posts

Here is my presentation from Zapthink's Practical SOA conference in New Jersey back on March 25. My topic was How to Sell SOA to the Business. My three key take aways:

  1. Align SOA w/Business Drivers
  2. BPM is the Killer App
  3. Speak in Business Terms


Click this link and go to the 4th video (you must register on Zapthink...it's free)


Feel free to leave comments or send me your questions at mkavis@yahoo.com.



I attended Zapthink's Practical SOA event on Tuesday in New Jersey. There were many great presentations from both vendors and practitioners. There were three different case studies presented including mine which was on selling SOA to the Business (the video will be posted soon). What was interesting to me was the three different paths the companies in these case studies took. The first case study was from The Hartford. They have a well established governance model and are very far along into the maturity model. If you read a text book on what SOA governance should look like, it will look like the Hartford. They have their processes so buttoned up that they even tie developers' annual review process to how they adhere to Hartford's best practices in reusability. A key take away is the fact that this took several years and a firm commitment from their leadership team to put this in place.

The second case study was from Lehman Brothers which was implemented in a totally different fashion. In this scenario, the governing body had very little control and power over the distributed development groups. So instead of just giving in and giving up, they took a different approach. They leveraged tools and some custom code to discover web services and usage of services in the repository. They would receive a page anytime a new service was discovered. Then they would study the service to see if it was constructed the proper way. If there were opportunities for improvement, the governance team would engage in conversations with the service owners to coach and mentor them on the proper design and deployment of their services.

In my scenario, we have a totally different story. Because we were so successful in selling the business on BPM and SOA, they funded the initiative and targeted very aggressive delivery dates for key functionality. That did not leave us enough time to plan and implement a governance model. So we are establishing a road map for delivering governance one step at a time. We understand the risks of not having enough governance up front and expect some headaches along the way, but the business was not going to wait a year for us to put those processes in place.

So theory and text books say that you must start with governance. The reality is you evolve governance over time. I highly recommend attending these Practical SOA conferences if you get a chance. I jokingly refer to it as group therapy because we are all sharing our lessons learned.
If you missed the conference, there are two more scheduled. The next one is in London on April 25 and the last one is in Las Vegas on May 16. I also highly recommend the LZA SOA Bootcamp which I recapped a while back. Ron at Zapthink told me that they are targeting May 5-8 in New Jersey for the next boot camp if they get enough people interested in it. Send Ron an email at info@zapthink.com if you want to attend.




I summarized day 1 and day 2 of Zapthink's LZA SOA Bootcamp. This post will summarize days 3 and 4 and provide my overall assessment of the class. The last two days covered topics like testing, governance, SOA Pilots, BPM, funding, and pitfalls. Here are some key take aways:

One step at a time. Just like establishing an EA program from the first time, you need to start small, iterate, make adjustments, and move on to the next challenge. Implementing SOA is a long journey. Don't try to do it all at once!

Abstraction is the key. Your services should be vendor independent (ex: should run on any ESB without changes to the service), business process independent, database independent, etc. If this is not the case, then you are not doing SOA. Most likely, you are doing ABOS (a bunch of services).

The "Tipping Point" - If you do SOA right, you will reach a point where you shift from creating services to consuming services. When you find that you are spending most of your time assembling SOBAs (service oriented business applications) then you know you have achieved SOA. Let the Lego building begin!


Start with a pilot. Don't forget that governance and architecture should be piloted as well. Don't just pilot services. It takes services, governance, and architecture to create SOA so don't leave any of these out of your pilot.

Design time governance - Ensure that team members are following best practices that apply to services. Governance should not be a burden and a ton of paper work. It should be value add and help the team build a true service oriented architecture. Design time issues include versioning, metadata management, policy management.

Run time governance - Enforce and monitor run time policies and SLAs. Service development doesn't stop when a service is deployed. The service lifecycle continues through run time. We must plan for ongoing change of services. Run time issues include service availability, policy enforcement, SLAs, controlling total cost of ownership (TCO).

Don't test the architecture - Test the individual components and how they integrate together. Divide architecture into domains and verify the domains. Things you need to test: services, security, business processes, integration, and also the governance. Services should run without dependencies. Test services across multiple platforms and test for abstraction.

Funding and the business case - Don't talk about the technology, talk about the business problem! Here is how I sold SOA at my company. Key drivers are reuse, greater visibility into business processes, business empowerment, business agility, lower integration costs. Create a roadmap and estimate the each deliverable along the way. Don't forget to fund the organizational changes, training, and support.

SOA Pitfalls - Don't let the vendors or consultants drive your architecture. Create versioning policies. Without these you may not achieve loose coupling because you might break the contract your services have with their consumers.

Organizational challenges - Here is the biggest challenge of them all. You can always find a bunch of smart people who can figure out the true meaning of being service oriented. But how can you make people change? Remember the days of trying to get mainframe developers to adopt client server? Get ready to live those days again. Since SOA blurs the lines between applications, middle managers may look at SOA as a threat. Typically, the architects do not have the enforcement power/authority needed to enforce best practices. This is a major challenge with SOA.

Still maturing - SOA best practices are very dynamic. This technology is still maturing and the vendor tools and standards are still evolving.

What's next? - Web 2.0, Enterprise Mashups, and complex event processing all are natural extensions of SOA.

Final Summary -
This was an outstanding class. I highly recommend this class for any organization that plans on tackling SOA. Jason Bloomberg was a fantastic teacher who kept us all awake and interested for four days. The Jeopardy exercise at the end was a nice way to finish off the bootcamp. We had many hands on group exercises and student testimonials that helped balance the content between slides, discussions, scenario planning, and lesson learned. This class was some of the best money I have spent to date on my SOA initiative.



Day 2 of the LZA Bootcamp proved to be another solid day packed with great information about SOA. Today we covered abstraction, SOA and legacy systems, data services, XML, and security.

Here are some of the key take aways:

Abstraction - The business doesn't care how the service is built or where it is located. All that matters is that it works. Business services abstract both data and application functionality.

Legacy - SOA impacts Legacy in three ways.

  1. Migration - You can use SOA to migrate off of legacy by abstracting the interfaces and then gradually replacing the pieces on the backend.
  2. Enablement - Expose legacy capabilities and data as services.
  3. Rejuvenation - Leverage legacy as an active SOA participant. This is common with mainframe systems today. Many companies have fully functional mainframe systems that need to be connected with each other and presented with new rich interfaces.
Data Services - One of the biggest problems integrating systems is dealing with data issues across systems. abstracting data as a service allows you to hide the complexity of the physical implementation of data from the other layers. Here is an example of its use. Let's say you have four different sources of the same data entity that has four different data structures and leverages four different technologies. The data service layer hides all of this from business services. Then let's say you have a goal to reduce the data sources down to a single source. If your business services are calling a data service that represents the logical representation of the data, then you can eliminate the other three data sources without making a change to your business service. In other words, your business service does not care how or where your data is stored.

XML - XML allows for standardization and maximum flexibility, but it sacrifices performance. XML is a widely accepted standard and leveraging it gives you the ability to connect more easily with external services. However, since XML contains huge amounts of metadata and is Ascii, it can consume large amounts of network bandwidth. This can be addressed with hardware and software solutions that compress and accelerate XML messages.

Security - SOA increases the risk of security breaches. In addition to the normal dangers (SQL injection, denial of service, buffer overflow, and trojan horse), XML adds XML injection, WSDL scanning, schema poisoning, and other threats. In the traditional distributed computing world, systems were closed and API's were proprietary. With SOA, we have open systems and distributed APIs. A much larger effort is required by architects to keep the "bad guys" out.

Day three focuses on governance and funding. I'll be back tomorrow for a quick recap on those topics. Here is the recap from day 1.


My company is hosting the current Zapthink LZA SOA Bootcamp this week. We have a mixture of attendees from various government agencies, consulting companies, and from the marketing and advertising industry. The class is being taught by Jason Bloomberg from Zapthink who knows SOA inside and out. I highly recommend this class for any company who is trying to implement SOA.

Day 1 was focused on the fundamentals of SOA and service-oriented analysis and design. I'll highlight some of the key take aways below.

Companies require agility. IT needs to respond faster to change. We must architect to change.

The reason for architecture is to support the problems of the business. In my opinion, many times architecture focuses solely on IT and forgets that we are here to enable the business to meet its objectives.

Service Oriented is a business concept. Many people think SOA is all about connecting things. SOA is really all about enabling flexible business processes and providing agility.

SOA is architecture. You can not buy SOA, you do SOA! It is a set of best practices and the discipline to follow them. SOA is all about abstraction and creating loosely coupled business services. These services should be interoperable, unbreakable, reusable, and composable.

SOA is not Web Services and Web Services are not SOA. SOA is an architectural approach while web services are a standards based interface. You can do SOA without web services.

SOA is distributed computing. SOA shifts us towards decentralization and empowers the business. It simplifies things for the business but greatly increases the complexity for IT. IT can no longer ignore governance if it wants to successfully implement SOA.

SOA doesn't replace anything, it extends it. The beauty that I see in SOA is its tie to BPM. I can deploy a brand new workflow driven, composite user interface that leverages SOA to extend the life and value of years of legacy systems, without having to spend years rearchitecting fully depreciated and working systems. In other words, I can provide the business with more modern tools and optimized workflow without blowing up my existing systems.

SOA is not about portability, it is about interoperability - If your implementation is dictating a certain technology, then you are not doing SOA. You must think in terms of the business. The business doesn't care if the you use Java or .Net, the business only cares that it works. You must architect the business service in a way that the underlying technology does not matter. Changing the underlying technology should not impact the business services. Think of the universal remote control. You can program it to work on any brand and on multiple devices (TV, VCR, DVD, CD, Home Theather, etc.). The remote control has no idea how the technology is physically implemented or even what it looks like. It does know how to send messages back and forth to the devices.

SOA is declarative not programmatic. This means that the business logic is configurable as opposed to being hard coded. SOA provides the ultimate flexibility and agility.

SOA supports business goals. With this mindset, software plays the supporting role as opposed to dictating how the business works (ie. SAP, PeopleSoft, etc.).

BPM is the killer app. You can't do BPM without SOA and visa versa. Integration is a side effect of enabling business processes.

This summary is just a fraction of the wealth of information that was shared today. In addition to the great lecture and corresponding slides, the class had numerous group exercises that allowed the different companies to share their personal experiences from their SOA projects. These experiences were just as valuable as the presentation. All in all it was a very productive first day!


I will be giving a presentation at Zapthink's Practical SOA event in New Jersey on March 25. If you are attending the conference feel free to drop me a note if you would like to meet and discuss technology. I will be discussing how IT was able to convince the business to take on and fund a large BPM/SOA initiative and how it is transforming the company. If you haven't already registered for the event you can do so by clicking here.

My company is also hosting the next Licensed Zapthink Architect (LZA) Boot Camp in St. Petersburg, FL next week from 2/26-2/29. There are still a few spots available but hurry because they are filling up fast. Here is the link to the agenda. I recommend the Hilton which is in walking distance from the facilities.

As I mentioned a few weeks back, I have partnered with Zapthink to secure a four day Licensed Zapthink Architect (LZA) Boot Camp in St. Petersburg, FL from February 26-29. We have close to 20 people registered to date and have room for several more. By the way, it's sunny and over 70 degrees here! For those who like the cold or would prefer to attend a one day event called Practical SOA in Newark, NJ (home of the world champion Giants), go to this link to register for the March 25 event. I will be attending this event and might even be speaking about a case study that I am involved with. I will update everyone when I know more.

I will be attending the Gartner EA Summit in Orlando on June 11-13 and SOA World in New York city on June 23-24. If any of you plan on going to these events and would like to meet to talk technology with me, drop me a note.

Here are links to the events that I am attending:


Subscribe to: Posts (Atom)

My favorite sayings

"If you don't know where you're going, any road will get you there"

"Before you build a better mouse trap, make sure you have some mice"