SOA Integration Ninja

Top Ten "You know you are an Integrator when..."

2008-09-19T12:18:00.001-06:00

1 you recognize people by their operating system, hardware model and major application portfolio.

2 friendships are governed by a Service Level Agreements and/or Service Contracts following the WSDL standard.

3 you consider yourself bilingual because you speak English and XML.

4 asked what you do for a living, you invariably default to “making computers talk to each other” or avoid the question altogether.

5 you know that loose coupling is not synonymous with wife swapping.

6 no matter who you talk to, you see them as either producers or consumers.

7 you understand their are differences between City Transit and the Enterprise Service Bus.

8 when you take a phone message it is by default real-time, guaranteed and fault tolerant.

9 you struggle for hours to understand the semantic meaning of those ‘extra’ charges on your cellular phone bill.

10 metadata is not a dirty word.

SOA Training

2008-08-21T11:35:00.002-06:00

I received a question from a client regarding what value training would be if some students were skilled in the relevant technologies, some were modereate and some were newbies. I thought my reply was worth a BLOG. Let me know.

Having a variety of student skill levels take the same training is a normal and expected situation amongst many adopters of SOA technology and middleware platforms in particular. The overall goal of the classes is not only to teach basic skills but build a common shared understanding of how the tools are being used, or could be used, to build a solution.

The experienced students bring thier past expereinces (success and failures) to the class and at the same time they can validate their approach and understanding. They may learn different things than the newbies but they do pick up new skills or reinforce their confidence that they are using the tools correctly. thier presence makes the less skilled more confident in the overall team's chances of success.

The newbies benefit the most in this situation since they learn from not only the instructor but also from the combined knowledge of the other students. Integration platform software is complex. You will be hard pressed to find someone who would not benefit from reviewing the basics through instructor lead training. If the 2-3 highly skilled students still want a challenge, they can be charged with learning how to teach the class the next time to the next set of newbies.

If an organization wants to adopt a more SOA approach, they would send Business Analysts and Project Managers to the training as well. They may not be expected to build solutions, after taking the training, but they should learn how to "speak the language" of the builders.

In conclusion, technical training will raise the overall competencies of all team members so they can be expected to deliver rock solid solutions using integration middleware platform software. Having skilled students sit through 7-10 days of what they may think is 'a waste of their time' is a small price to pay for long term success. I assure you, it will not be a waste of anyones time!

The SOA Ninja

Forrester EA Conference DAY 1 Highlights

2008-02-08T01:22:00.000-07:00

Well, the whole day started ff with the introduction from Gene Leganza from Forrester introducing the theme - Innovation. It does make sense since the role of enterprise Architects is truly at the "intersection of business and technology". This is a direct quote from gene. He went on to summarize the finding of a recent survey regarding he most important IT concepts/issues: 1. Agility, 2. Technical Support with all the others getting equal but less billing after that. the first issue is directly related to SOA in that agility is the capability to change quickly and efficiently.

Mike Gilpin from Forrester was up next with a talk on innovation stating that 'innovation should be simplifying". I would go on to summarize the idea itself should be simplifying even if the actual implementation is difficult. This stuff is not simple!

Michael kept mentioning the impact the recession might have on businesses adopting innovation ideas. It seems odd that this was brought up at all? He was optimistic regarding the capabilities inherent in innovative technology to help organizations pull through the down times. Hardly screaming optimism but practical advice I suppose.

Rapid, iterative development was espoused as a new best practice but of course it is tempered by Forrester suggesting that only some projects be given the mandate of not adhering to actual deliverable dates imposed arbitrarily when we all know that most projects should never have to undergo some effort estimate based development like we are plumbers or brick layers. We are more like artists, apply the craft of technology.

Here is a list of Innovation Adoptions best practices you can take home....

Hire/promote innovators, not police
Recruiting templates should add innovation as a skill set
Bring business leaders into EA
Immerse technology people into the business
Ensure there is an executive vision and that it is shared
Architecture teams work with business
Institute innovations labs with technology experimentation
Establish mentoring programs
Rapid prototyping
Manage and mine your idea portfolios
Take 3 perspectives: STO Strategic, Tactical, Operational
Market your efforts

Hub was great as the keynote speaker. It makes me proud to work for progress and I really hope he doesn’t read this since that’s not why I mention it. Simply put, if your executives are aligned with your overall vision, it makes doing your job that much more fun. Hub emphasize three more best practices that sum up the approach espoused by Progress Software:

Connect interactions freely
Mediate policy actively
Control semantics precisely

One interesting note is that Forrester has introduced a Vendor agnostic tend tool, similar and yet complimentary to the Wave. It is called Tech Radar and it predicts trends in technologies areas trying to predict which trend or fad will make it or break it. Plotting each trend related to the adoption maturity curve.

Got to get come sleep. We took a few good friends to the gaslight district of San Diego and had a blast. That’s the perks of this job - the people are great! Did I tell you we are hiring. Perhaps not? Keep Progress in mind if you like cool technology and working with bright and enlightened technologists. A winning combination.

Stay tuned for DAY 2. I think we are going back across the border?

Forrester EA Conference San Diego Feb2008

2008-02-07T07:58:00.000-07:00

Well, a new beginning for the SOA Ninja. It has been a little while since I last wrote a BLOG entry. In fact, it was Nashville at the Gartner Integration and EA conference. Since then, I have joined Progress Software and since they are platinum sponsors of this conference and it's so close to Tijuana, I thought it appropriate to attend. With that out of the way, I will start with some suggestions.

7Feb Track Suggestions:

9:30 Don't miss the keynote from my CTO Hub Vandervoort. He has a great e-book on Socially Oriented Architecture as well. SOA rebranded!

10:15 meet me in the Technology Showcase, checking out the Vendor booths.

11:00 TRACK B - The Critical Importance of Business Context to Architecture Initiatives, Kyle McNabb, Forrester Analyst.

1:15 CONSELLATION A - IDS Scheer - Enabling EA (I like their products. They have a good story regarding SAP configuration design).

1:55 TRACK C - The Architecture of Dynamic Business Applications, Randy Heffner, Forrester Analyst.

After that, you are on your own. I will check in later today and BLOG key findings from these presentations. Stay tuned. Here are a few random observations already:

- San Diego is a border town and the sound of the gates at the border clacking was odd, especially the long cement corridor posing as a border. No inspections, just walk and be observed. Easy as pie. Coming back is a bit of a challenge but not like Canadian Customs.

- If anyone asks, yes, it’s a real Rolex. At least that’s what they said when I bought it.

- SOA has reached general acceptance. The concepts are riddled throughout the agenda. Very cool! I hope it's not just a passing fad or at least lessons are learned along the way.

Later,
The SOA Ninja

IC Calgary Chapter Breakfast 20Feb:
http://calgary.icmembers.org/
Blackbelt SOA Training 3-7Mar:
http://www.progress.com/cgi-bin/educ.cgi/details.w?id=1056
IC Enterprise Architecture and Integration Summit 12-13May:
http://eaic.icmembers.org/
Progress Exchange 2008 Paris 8-11Jun:
http://www.progress.com/exchange/2008/

Nashville Gartner Spring Summit 2007 - First (and ONLY it seems) Thoughts

2007-06-15T10:32:00.000-06:00

It should come as no surprise to anyone that I was thrilled to be able to attend what I believe is currently an influential gathering of IT thought leaders. I met some of them and exchanged wonderful stories (best practices) from leaders at GM, EarthLink, Lowes, IDS-Scheer, Progress, University of Illinois amongst many others. IMHO, It is this gathering of global thought leaders that makes this conference attractive.

Here are my observations from the event. I hope you find them useful.

Gartner AADI Summit 2007 11-13Jun2007
Application Architecture, Development and Integration

Gartner EA Summit 2007 13-15Jun2007
Enterprise Architecture

Nashville, Gaylord Opryland Resort.

Session 1 - 10Jun Pre Conference Session – AJAX Limits, RIA Tech Risks and User Experience Possibilities.

Broke down the categories for RIA into this taxonomy:

RIA
Browser
No-plugin
AJAX
Plugin
Flash/Adobe/Laslo
.NET Silverlight
Java
Outside Browser
Short
Java
Webstart
Digital Harbour
.NET
Tall
Flash/Apollo
Java
Eclipse
IBM
.NET

The levels of AJAX adoption are:
Level 1 – snippets like validate postal code
Level 2 – widgets like a popup calendar
Level 3 – Client side framework
Level 4 – Client and Server side framework

The most benefit from AJAX is when it is used to automate simple data entry applications and pre-defined multi-step processes. This accounts for 80% of the applications that are required. Other technologies may be considered for the more complex needs (the other 20%), if this would provide value to the business and adequate support funding is in place to warrant the investment.

The concept of ensuring solutions go through usability processes and are vetted against what was called a User Interaction Patterns set of best practices. The things that should be considered when holistically designing the user interactions with the technology.

Session 2 – Complex Event Processing

This session disappointed me somewhat since it started the mantra of separating the idea of event driven architecture for the realm of SOA. In fact, that was the main theme of the keynote address. In any case, complex event processing is way cool and right on the mark regarding the need for abstraction. This abstraction is represented in CEP (Complex Event Processing) through 3 maturity levels:

Event Processing – publish and subscribe (MOM, WS, ESB, E-mail, RSS)
Basic Event Mediation – Transform, route
Complex Event Processing – Filter, Aggregate, Correlate

I consider this a great way of explaining basic abstraction concepts that didn’t really need a new term (CEP I mean). But if this wakes people up to the need to build this kind of abstraction into simple tool interfaces, I am all for it.

Here the definition of what is SOA, that pissed me off. It must match these criteria:

Engineered modular services
Modules/services can be distributed
Modules/services have formal interfaces
Module/services are reused/shared

Notable quotes:

“How many centres of excellence do you need?”
“Make EDA part of your SOA strategy”

“To be a Ninja, one must be a wizard. This means that he can "stop the world" and "see
with the eyes of God."
Ashida Kim, Secrets of the Ninja, DOJO Press 2000

Session 3 – Keynote – Challenges of Irresistible SOA

I gathered quite a number of nuggets of information from the keynote. Here they are in point form.

- SOA and EDA have been split and a new discipline emerged, known as CEP.
- Salesforce.com was quoted as a great example of an emerging trend SAAS (Software As A Service).
- WOA is defined as Web Oriented Architecture (REST/POX + WWW and web services)
- Emerging technologies are RSS, BLOG, AJAX and WIKI
- Multi-step integration challenges are being forefront on the minds of technology leaders.

Integration patterns were discussed, with a prediction on the types of integration being solved at organization around the world now (2007) and in 2012. These are the predictions:

Point to Point 2007 – 60% 2012 – 30%
Hub and Spoke 2007 – 30% 2012 – 45%
Distributed 2007 – 10% 2012 – 25%

Great speaker Ben Lheureux

Same analysis was done for the BPM activity. By the way, I don’t agree with these numbers in particular. The use of BPM models to only model process and not monitor and even allow the runtime environment to be changes, given a model drag and drop operation is a key fundamental belief I hold regarding the vision for SOA. It must happen sooner or the simplicity we need to deal with the increasingly complex automated technology will not provide the business value we anticipate. Anyway – stop ranting. Here are the numbers.

Model Process 2007 – 30% 2012 – 60%
Monitor Process 2007 – 20% 2012 – 40%
Execute 2007 – 10% 2012 – 20%
Orchestrate (I added this level since Gartner missed it !!!)

Data Integration numbers were provided as well:

Batch 2007 – 80% 2012 – 50%
Near real Time 2007 – 15% 2012 – 40%
MDM 2007 – 5% 2012 – 10%

Notable quotes:

“Just Enough Process” – seems this is the mantra of Gartner this conference. Just enough modeling, just enough as-is evaluation, just enough whatever and then get on with solving the business problems. Show results!

“Governance is a weasel word”
“Six Sigma is TQM in sheep’s clothing”

“The Ninja do what must be done, then it is forgotten. Princes and kings may gain some
temporary advantage through Force. But, the only lasting accomplishments are achieved
through Love.”
Ashida Kim, Secrets of the Ninja, DOJO Press 2000

Get IT done.
More conference proceeding to follow. It’s time for me to head to the airport.
Stay tuned – I attended an Oracle presentation by Dave Chappell – very cool!
The SOA Integration Ninja

5 minute video explaining web 2.0 Fantastic

2007-05-18T11:55:00.000-06:00

Hi..
Here is a link to a YouTube video that explains the concepts behind web 2.0 very nicely.
Enjoy!

http://www.youtube.com/watch?v=NLlGopyXT_g

Extending Legacy Systems

2007-05-01T17:03:00.000-06:00

Recently, I was interviewed by a freelance journalist from ComputerWorld. Just in case I only get a one line quote, here are the questions and my written answers.
Enjoy!
Murray
The SOA Integration Ninja

1. What is new in the area of keeping legacy systems going?

Adapters for legacy technology are routinely being used as wrappers for legacy functionality, promoting the reuse of this functionality within new and different business processes. While adapters have been available for legacy systems for many years, it has only been recently that standards for these adapters have been ratified. The WS-I (Web Services Interoperability) specification and the Web Services SOAP standards have been embraced by the software industry. Software vendors are just now releasing adapters, based on WS-I and SOAP, that allow legacy systems to ‘play nice in the integration and SOA sandbox’.

2. With web front ends, is there any reason to retire legacy systems rather than just giving them a new UI?

Most legacy systems were built to perform a specific set of functionality in a controlled and governed environment. When this functionality is exposed as services through a new web front end, the additional burden this puts on the underlying infrastructure and increased traffic may necessitate replacement of the legacy system rather than give it a new UI. Web front ends are often just lipstick on a pig. But you don’t shoot the pig that keeps winning you blue ribbons at the fair and you don’t retire your legacy applications when they continue to add value.

3. Is the retirement of IT workers leading companies to update their systems because they can no longer easily find personnel?

Not only is the retirement of workers causing IT shops to update their systems but also the rapid pace of change that has been embraced by the business. Users of corporate systems have come to expect the jazz of rich user interfaces and the experiences promised and delivered through web 2.0 technologies such as BLOGs and RSS. The ‘green screen’ is dead and is not tolerated for long amongst even the most inexperienced User that has spent more than a few hours browsing the internet, including Google, MySpace and YouTube. Business users have come to expect that their corporate applications can change at the pace of business. This pace is furious.

4. How should one decide whether to retire an old system or keep it running?

There is no magic or advanced formulae that should be used make the legacy retirement decision. A simple cost-benefit analysis weighing the pros and cons is still the preferred method of decision making. These decisions are almost always based less on the technical merits of the legacy system and more on the non-tangible aspects such as the projected lack of qualified technical resources for support and maintenance, vendor relationships and increasing total cost of ownership.

5. What are some mistakes people make when extending legacy systems?

When extending legacy system functionality, people often turn to the experts who wrote the system in the first place. These individuals are then asked to write code in a language unfamiliar to the majority of the remaining IT shop. While this seems the most cost effective approach at first, it is this fatal mistake that continues to tie companies to the legacy systems and the business processes it is able to support. The new paradigm is to leave the existing legacy functionality as-is and extend through standards based service interfaces. These services are then made available to orchestrate within agile workflow modeling software. The extensions are written in the latest technologies such as J2EE and .NET, with rich user interfaces and hopefully, breathe new life into the legacy systems value proposition.

6. What are some best practices they should follow?

A set of best practices, known as SOA (Service Oriented Architecture) has recently been adopted by the IT industry. SOA is based on the realization that change is ever present, moves at internet speeds, and that systems should be built in anticipation of having to change. The SOA vision of business and IT agility is realized through the introduction of a services layer that is based on industry ratified standards. These standards cover event-driven architectures, JMS, Web Services(SOAP), XML, BPEL, and industry standards schemas. Organizations should look to expose their legacy systems functionality as services using these standards.

BPEL Unmasked

2006-12-01T15:41:00.000-07:00

Here is an initial BLOG I wrote and never posted. It was written 1 year ago today and even at internet speed, it is still relevant.

During discussions with a few integration consultants in the Calgary office, we started to brainstorm the usefulness of BPEL to the market/clients/businesses. That is, what value proposition does it bring, other than the Middleware vendors having a marketing line on their brochure that says BLEP Compliant?

This is not a story of what BPEL is, you can look that up yourself, but it seems the proposition of having process flow definition represented in XML was supposed to allow interoperability with design/modeling tools so that the Business Process models created by the Business Analysts could be imported into the Middleware Process Repository/Toolset. Big hairy deal. In fact, the process of creating these flows from scratch is truly the simplest part of the Integration Solution development challenge (most demo’d I'm afraid) that this provides no or little time savings.
What BPEL does provide is the establishment of a STANDARD to limit each process modeling tool (technical implementation) so that the models created in the tool can be read/interpreted by HUMANS as meaning the same things. That is, limit the UML plethora of models and notational references (icons) into something that can be easily understood by the business and implemented within BPEL aware tools. This is the power and the value proposition, not the technical importation of models or the representation of them as XML, on or off of the multi-part message itinerary, since it matters not.

Stay real!
The SOA Integration Ninja

Ninjas Needed ASAP

2006-11-10T08:37:00.000-07:00

Well I never thought I would turn into a recruiter but it turns out my firm has secured a couple of large projects in the new year, all dealing with Integration and SOA technologies. I can’t do all the work myself and so I am looking for other to join Online Business Systems and my team in delivering SOA/Integration solutions to our customers.

This is an open plea to confident application developers, data modellers and support analysts to make the move to consulting. We provide challenging opportunities, 3K yearly training allowances and a stimulating work environment. Really, I do like it and I am placing a bet that you would like it here as well. My firm pays for relocation from all over the world and we are experienced in helping with immigration issues, etc. While we have offices all over North America, I would like you to consider moving and working out of Calgary, Canada.

Drop me a line and I will personally call to discuss these opportunities. No pressure just an honest offer of employment. Consider this quote from Ashida Kim, my Ninja Mentor, “One cannot embark on the path of enlightenment all at once…”. Make the first step and come join me on the journey of a lifetime!

See you soon!
Murray Laatsch
The SOA Integration Ninja

Edmonton CIPS Conference Day Two 7Nov2006

2006-11-09T08:23:00.000-07:00

I apologize for being late with this instalment but it appears I have a real job with actual deadlines so writing a BLOG ends up lower on my priority list. Go figure? For this very same reason, my ranting will be short and to the point. Lucky you!

Session 1 Role of an Enterprise Architect

Architect delivering this ‘course’ was well spoken and I gleaned a few lessons learned from the material. Here it is in point form.

.TOGAF – This methodology was mentioned yet again as a reference point for architecture.

.Level 1 and Level 2 OMG Architect Certification is recommended. I agree and I intend on reviewing the course material and certification requirements before I pass judgement. But, on the surface, it sounds good and I can vouch for the credibility of the organization overall. They are part of the Integration Consortium and the representatives that I have met and the material on their site is first rate.

.Roles for the Architect include:
- Take responsibility
- Put your own credibility on the line
- Risk not Assumption so you get a mitigation plan and try to avoid blame game
- 2 week revisions on Architecture deliverables – refactoring essential
- Make people feel smart
- VISION, ROADMAP, EXECUTION
- Empower and step back to let others shine by supporting them 110%
- Know who has the Power and make them look good or make them feel/look smart

.Concerns and Questions from The SOA Integration Ninja
- Agility of the Options/Recommendations approach must be emphasize3d. Always expects change
- UML Standards for modeling were not emphasized. I think they should be
- The Zachman Framework was not brought up and I believe this deserves more emphasis as a resource for Enterprise Architects. Balance this methodology with TOGAF and with what the client wants and understands. Bingo – you are thinking outside the box.
- I am always frightened that the role of an architect changes into a justifier of change orders when the project is funded through a Fixed Price model.

Slides are available for this architecture presentation on the ice conference website. I would encourage aspiring integration consultants to understand and consider working towards a role as an Enterprise Architect.

Session 2 (My Work, Not the Conference Stuff)

I find myself in my hotel room working on a Service Design Process Model for a client. I will return to the Conference for a social event this evening and return home tomorrow morning. I discovered/designed a sublime method of providing Service Contract metadata with policy assertions, that I would love to share with you. Now, this is based on a design pattern that was proposed for the Provincial Health Integration Engine (Hub). This design included a service management front end with Oracle data structures that represent the metadata that would influence the runtime behaviour of services (parameters). Instead of this approach, which involves the creation of a front end administration module and a set of data structures, my more modest clients have turned to XML Schemas to define the contract/policy metadata. As an XML instance, the management can be through any XML aware admin console, even stooping to using IE Web Browser (read notepad) or some utility (preferably with Stylesheet support) that provides security administration capabilities with XML Schema editing.

The approach centers around the design of a contract XML Instance for every business service that is created and deployed. As the service runs, it uses the attributes on the instance to stamp the context for the event messages with the information maintained within this service contract. This occurs as the first step in a service process orchestration. After which, the service needs no further knowledge from the requestor or producer of the event since that context is provided through the contract (physically though the XML Instance).

Anyway, it seems much more important in my head as a design concept that it does as a revelation on paper. It deserves more respect and so I may write more in an upcoming whitepaper I am currently writing for the May 2007 Integration Consortium Summit(s). If you would like to write a paper, the call is open with details on their website.

“When there is no justice, the Ninja appear. They are not called to action by anyone.
They are just ordinary people in extraordinary situations. They need not have a clan or
credentials, or even a great deal of training. They only need the Will. The Ninja do what must be done.”
Ashida Kim, Secrets of the Ninja, DOJO Press 2000

Get IT done.
The SOA Integration Ninja

Edmonton CIPS Conference Day One 6Nov2006

2006-11-07T06:42:00.000-07:00

Welcome to the CIPS ICE conference in Edmonton , Alberta, Canada 6Nov-9Nov2006. Check out www.iceconference.com for a complete agenda. But, Edmonton you ask? Yes, the SOA Integration Ninja finds himself in the hinterland attending the first day of a four day conference dedicated to the IT industry in and about Edmonton. I will attempt to cover the proceedings so you feel as if you are attending yourself. If you behave yourself and ask nicely, I have safely preserved the prestigious leather case, complete with calculator (donated by ATCO I-TEK ) that was given out as part of the giveaways/graft for all attendees. It is yours for the asking.

On with the commentary then!

I started off the day meeting with Jason Bloomberg, of ZapThink fame, since he was asked to present at both a morning presentation and an afternoon follow-up. It is these sessions that are the primary draw for me. I am, of course, an honorary member of the ZapThink architecture alliance J I respect these gents for their non partisan stand on the benefits of Architecture and SOA in particular. Online Business Systems has sponsored an entire track, placed a full page ad in the Agenda and sponsored a table at the executive dinner this evening. Read on for my comments about the day. Enjoy.

The day started with a keynote regarding nanotechnology. “Not your favourite breakfast topic” one fellow conference attendee at our table noted. I truly struggled to find relevance to the keynote until the very end. Surprisingly enough the relevance has a lot to do with SOA in that it highlights the need to approach business problems from different perspectives. The lessons learned is related to the aspects of building in less of a margin of error since nanotechnology designed products that can convert raw molecules into machines that can then manufacture/construct at a larger nano level, other machines. These machines build larger structures/machines that in turn build to a larger scale until something we can actually be seen is built (in relatively short time) and it matches exactly the digital model that is its very design. A replicator from star trek comes to mind and this is the exact metaphor for SOA such that what you imagine technology is capable of doing will and can be done if you are able to assemble and construct the building blocks, starting even from the sub-molecular level.

Above and beyond the building blocks analogy for SOA is the reiteration that SOA is about thinking outside of the box and embracing new technologies to enable business agility. What a simple solution to be able to design an object using a model and have it manufactured from raw molecules. Simple and powerful abstraction and soon to be a reality I would bet.

Session 1 Business Case for SOA

This session is part of the overall ZapThink material that Online Business Systems has been certified to deliver through their certified Architect program. There are 10 courses/sessions that revolve around the book ‘SOA or Be Doomed’ and Jason delivered the first summary/introduction material to an appreciative audience of over 100. The people attending come from all aspects of IT delivery, CIOs, IT Managers, Architects, etc. A very broad audience indeed. The session went well, as always, with a highlight being the distribution of the ZapThink SOA Roadmap posters. I have a few if you are interested. Drop me a line J Remember though, a real roadmap is hammered out internally and the poster is to help you visualize one path, with considerations for completing your own roadmap for your own company. This concept is hard to grasp since everyone seems to want a silver bullet or set of 10 things that if they follow them, will lead to SOA panacea. Of source, software Vendors will play into these desires and make promises in order to close the sale. Did you buy SOA from your Vendor? I think not. But whatever allows you to sleep at night is OK sometimes.

I have the slides for this presentation and the next one and in fact, the entire 10 modules along with 2 bonus modules that cover the emergence of SOA Vendor software and a set of case studies normally presented only on request. I would love to share these with you. Through the ZapThink certified Architect program we are able to leverage this material to spread the good word of SOA as long as we give credit to ZapThink as authors of the slides. Great program and great session this morning.

Session 2 SOA Governance and Risk Management

Another well attended session with over 100 people, most of whom did not attend the morning sessions. Many companies buy corporate memberships and share them amongst staff. I noticed a few colleagues with whom I am or have consulted with in the past, attending this session. Not among these was one IT Manager at my table that said “I don’t really get this SOA stuff. It is new to me and I guess it will sink in sometime. I just have to keep getting refreshed.” I often wonder if the concepts of SOA are really understood by an audience and I believe that most DO get it or can take some aspect of what they learn and add value to their own project/initiatives. It is no wonder that SOA is best understood by Architects since it is Architecture after all J

Questions and comments form those that attended the first session were answered during this session, that focused on Policies and how policies, contracts and services fit together in the context of governance. I know this is a hot topic with a few projects in Edmonton that have been working towards the early adoption of SOA based solutions, are talking this problem already. The session provided excellent direction on the considerations for design but does fall short of providing a template for a policy (XML Schema for instance. Pun intended). I really want to materialize this concept and I currently have a client that is going through he design stage and in need of a metadata source for Service Contracts and their associated Policy assertions. So, as you can see, I really enjoyed this refresher and it was very topical for me and seemed to be well received by the audience.

Executive Dinner

This evening, I was accompanied by Joe and Joe from Online to the Mayfair Country Club where Online sponsored a table at the ‘invitation only’ executive dinner. The keynote speaker was a VP at Nova who was once the CIO. The talk centred around the successful rationalization of multiple Oracle databases into streamlined IT Operations such that plants are now operated by half the people and with a higher safety record to boot. The topic was interesting and the company at our table was very engaging. I will not name names since these are Executives with more of a reputation to uphold that I have. Needless to say, I was honoured to be in the presence of senior leaders within the Edmonton IT community. If you are one of these Leaders, pat yourself on the back. I am sure I talked way too much for some tastes but is very seldom that an Architect gets to sit with technology decision makers and gets the chance to perhaps influence (even in a small way) IT policy.
Topics of conversations revolved around call centre solutions, healthcare and the normal sharing of ideas and situations that occur in a social settings like this. One conversation the Ninja found engaging related to the general acceptance that the next generation could be termed ‘Gamers’. I first heard this term when reading an article in Wired magazine and it generalizes the new generation as being highly accepting of technology collaborations mediums (MSN, Google, YouTube, etc.). These methods are now an expected and normal way of communication. In comparison, we offer stringent tools to our people in the corporate setting. Very inflexible conared to what the gamers are getting used to on the we. That is the message that Web 2.0 is set to deliver to the world. A new wave of expectations by the basic system user that demand maximum flexibility and at the same time flawless execution. Kind of like Mortal Combat or the other gamers games like Halo, World of WarCraft, etc. that allow a gamer to interact with the environment, controlling almost every aspect of the game (imagine business workflow) by changing metadata. My Son spends more time on Play Station games managing the metadata related to how the game should behave than he does actually playing the game itself. The fun and the challenge is in controlling the entire environment through metadata. We are best advised to begin offering solutions in the corporate world that allow this type of customization, by the business. The gamers will demand it. Flawless Execution!

How to Identify Services for your SOA

2006-10-15T09:19:00.000-06:00

Greetings SOA Integration Pundits…

From Wednesday to Friday last week I delivered an in-depth SOA course, with Jason Bloomburg of ZapThink fame, to a group of Architects. Jason refers to this kind of group as an argument as opposed to a swarm, a gaggle or a herd. So, this argument of architects were particularly interested in how would someone identify the candidate services within an organization. This is a typical question since almost everyone who attends this course (Edmonton, Toronto, Illinois and now Calgary) is looking for a checklist that they can add to their SDLC. Well, it's not that simple and yet it is.

I have been identifying services using a technique perfected from a number of engagements, some known as SOA and some just expecting that the integration challenge at hand would be addressed in the most appropriate manner (SOA or not). Let the masses try to build something from these lego blocks but it takes practice and skill (both found at Online) to get it right. The Ninja says, enlighten the masses so they can build upon the success and failures of those doing the enlightening. Regardless, these techniques should be able to help get you started and if you are smarter than the average bear, well, please feel free to be enlightened. So read on SOA Ninja Minions and try these techniques. They work!

Overall, this technique is identified in Online circles as the Community Of Interest (COI) approach and it is a derivative of the sROAD (SOA Rapid Online Application Development) sanctioned methodology. I use the COI approach routinely and it is well received I think. The technique starts with a discovery session or review of functional decomposition diagrams, where high level information needs are attributed to the high level actors in a diagram loosely based on the UML Use Case convention. In fact, each model in this approach is based on UML which I believe is the only way to ensure consistent understanding (you do not have to reinvent the modeling constructs, just use them fit for purpose). I cover this technique in a whitepaper I wrote for the Integration Consortium Global Integration Summit in Boston last year. The paper covered the business of employee provisioning and followed the COI approach. All the diagrams are shown in this paper which is provided as a link on my blogspot.

You may recall that in the past, this diagram was subsequently used to identify Integration Events and then prioritize these events as a way to prioritize the integration project work that needs to be done for our clients. It is not meant for only the prioritization of project work! In fact, it is a multi-talented type diagram and it is uniquely suited to identifying information sharing needs that lead to discussions about the business processes which are lacking sufficient automation or face unique enterprise challenges. This is a key value proposition of SOA – Automate the business process and the integration happens as a by-product. But, in order to understand the business pain and identify the services that should be automated to address this pain, an examination of enterprise information sharing (automated and non-automated) is essential.

It is from a combination of examining the functional decomposition diagrams already in place(hopefully) and a few well placed interviews that services can be modeled/discovered using yet another standard UML modeling construct called Activity Overview Diagrams. I have perfected this approach and the use of this diagramming technique so that the model truly become the communication point between the business and the toolsets that IT will use to implement the SOA solution and the respective services. Please check out the link ‘COI Service Identification’ to view a whitepaper that contains a case study in the use of these techniques and the subsequent build of the solution in a variety of vendor software: BizTalk, Sonic and Tibco. We had teams of Onliners using the design models to demonstrate that regardless of platform, the design remained the same.

While the models that you use on your project may be dictated by the client or your PMO, please consider introducing the COI method and associated models to them early in the project initiation. No matter what UML compliant tool (Erwin, ProVision, Visio, whatever) you have at your disposal; you can create a ‘Service Design Process Model’ if you want to. Do you want to? Can you afford not to?

Regards,
Murray Laatsch
The SOA Integration Ninja

SOA and PMBOK - Stop the Madness!

2006-10-11T05:11:00.000-06:00

It occurs to the Ninja that most of the old style middle management types who have grown up with projects constantly failing, falling behind or out of control, do not grasp the fundamental shift in thinking that SOA demands. In the minds of these IT relics, SOA is just another sales job to the business to get them to fund the project in which the relics find themselves. Once the project is funded, the architecture is seen as a burden and an overhead and the relics fall back to the traditional Software Development Life Cycle and the well worn path laid out by PMBOK. After all, most projects are just a string of sequential steps roughly resembling: Requirements, Design, Develop, Test, Deploy. Or should I say: Requirements, Design, Develop, FAIL. Or some combination of FAIL and pick your phase.

This is pure madness. If the majority of IT projects fail using the antiquated approach suggested by PMBOK, and they do, why do we continue to jump behind the relics who flog this approach and claim that this time it will be better? We will be agile and we will get sign off this time or we will use an automated test tool. Surely that will prevent the failures of the past. Surely you are one of the relics if this is your belief. Wake up and smell the roses Relic. THE OLD WAY DOES NOT WORK. You proved it, now change!

The fundamental shift in thinking for an SOA based project is that there is no 'throwing the requirements over the fence' attitude. The Business Analysts, representing both the operational and the overall business architecture perspective, are involved in not only the requirements phase of a project but they play a major role in every phase. They are no longer just showing up to write some magical Requirements document and then showing up during Acceptance testing to sign a paper authorizing the garbage that was developed to be slammed into production. They must recognize that change to the business will occur during any/all phases including the development or design phases and they are responsible for recognizing and changing the project scope to react to these changes. These changes are constant and so their involvement is constant. Unless of course, nothing ever changes.

If you think(believe) that Business Analysts need only play bit parts during the initial and final stages of your project lifecycle, look in the mirror. You are probably a Relic. The sooner YOU change or leave, the better for us all.

The SOA Integration Ninja

Governance and Service Orchestration/Workflow

2006-10-06T20:44:00.000-06:00

During the 'Delivery Days' presentations on SOA today, Todd was able to condense the message of SOA into a single hour presentation. Very admirable attempt, however, 2 tenants of SOA were not identified as fundamental. So, my Ninja senses tell me to cover these two tenants (Governance and Service Orchestration/Workflow) so that his efforts to not go in vain. I know they were probably just missed because of time constraints.

Governance

All the plans of mice and men are doomed to failure unless someone is willing to execute the plans. Governance is just that. We have a plan to reuse and we say we will, but we never really expand this beyond individual project boundaries because of the autonomous nature of the business units, amongst other reasons. In any case, what mechanisms are in place to ensure governance? Is the Uuber BA and/or an Enterprise Architect within our clients organizations participating on reviews to ensure all the projects are sharing appropriately? Using Registries? Paying homage to the SOA Integration Ninja? How do we ensure vendors follow the rules when we bound them to fixed price contracts with little room for the extra work necessary to understand an environment? Well, we have the means and the technical tools to make amazing leaps in enterprise system connectivity and real value from composite applications, but unless you have the rigor to execute the plan and enforce governance, you will not reap the benefits proposed by SOA. This may not upset you, or your client, because all you both want to do is use the latest buzzword to sell your current initiatives. I know about you. Shame.

Service Orchestration/Workflow

As much as I believe Todd when he makes the ascertation that the Service registry is key to delivering long term benefits from SOA, where this reuse occurs is debatable. Since I like a good debate (non violent but severe) I will take up the challenge. The prospect of having a toolkit of services, which are composible into business processes and controlled through easy to change metadata, is utopian. However, the ideal to remove IT (Developers) from the picture, unless building new services, is not an unattainable goal. Tools exists that allow services to be represented within easy to comprehend workflow models (UML Activity Diagrams) some based on BPEL and whatnot but this value proposition is not about the use of standards like BPEL and BPMN, although important, it is the change in responsibility from IT People to the Business People for Orchestrating their services to meet the ever changing needs of THEIR business. This is certainly not unachievable since several of our clients are combining ESBs and Workflow products like POSSE, K2 and Lombardi to empower the Uuber BAs with not only a design time model of the business but a working production sandbox where the business can orchestrate, change, monitor and manage workflow ALL through metadata that effects the runtime behavior of underlying services. The reuse is present in this arena, allowing the business to reuse Master Data Reference services for validations and call string together individual services, such as: “Add a New User”, “Record Production Volume”, “Send Latency Notice”, “Generate Earnings Report”, for example, many times within multiple Workflows (jobs). Each would run somewhat differently, controlled by the business modifying the metadata to tweak the service to behave in an altered manner. Decision points and enterprise business logic would be reflected in the emerging/running models and even the panacea of BAM (business activity monitory) is possible using this platform since you can visualize where each workflow is by using the same model representation.

Whoops – rambled on their for a bit. So, time to sign off. On a final note, I was very pleased with the presentation made by Todd today. Just add these few addendum items (2 additional tenants covered above) and his material was bang on. Oh yes, and the business granularity of slide 11 or 12 is suspect. You know, the interfaces for the critical service contracts should be business related as opposed to algorithmic since they are being built for eventual orchestration by the now famous Uuber BA in his Workflow tool of choice J

I hope you enjoyed the rare presence of the SOA Integration Ninja himself, at today’s Delivery Day in Calgary. It was my genuine honor to be able to participate. Thank you. If you were not able to attend, the Integration presentation is posted to the Online Sharepoint site under SOA/Integration under the subtopic ‘Goals and Objectives’, I think. If you want it, you will find it dude.

Truth is only evident to the believer.

Murray Laatsch
The SOA Integration Ninja

What is different for the developer when building an SOA solution?

2006-10-02T17:27:00.000-06:00

This has always perplexed me. How do I explain the signifigance of SOA to a developer? In essence, it comes down to design specifications and standards such that they are encouraged (forced) to code in a certain fashion. I encourage you to attend Online developer days to hear from a developer, Todd Mackey, about his perspective. He will be comparing the tenant/principles of SOA to those held dear by the OO&AD crowd. The more things change, the more they stay the same.

There are some things that are new and even scare the most agile of architects. They include:

1. Coding for the service to behave in test and production mode, via a metadata flag
2. Event enable the solution such that high level interfaces can be portrayed in WSDL if you decided later that WS was a good idea after all.
3. Expect changing requirements
4. Build for change because it will.

Thats all for now. I will post the work from Todd after he delivers it this Friday.

Later,
Murray
The SOA Integration Ninja

Welcome to the SOA Integration Ninja blog

2006-10-01T09:39:00.000-06:00

Welcome to my blog!

I suppose my credentials are important to those that read my rants and so I present them here for that reason only. I am the Canadian Chair of the Integration Consortium www.integrationconsortium.org the current leader of their I-BOK (Integration Body of Knowledge) initiative and a Director of the local Calgary Chapter. As mentioned above, I am a Director with my firm http://www.obsglobal.com/ although I do not post on their behalf, they know I am doing this and they are very afraid :-) I am an affiliate architect with ZapThink, http://www.zapthink.org/ and in that capacity, I co-teach a 3 day SOA Course for the Intervista institute www.intervista-institute.com/soa.html I have delivered SOA and Web Services solutions to many clients and I prefer designing/building solutions to selling, managing or even blogging about them.

While it may seem, from my blog title, that I claim to be a Ninja. This is just partially untrue. I aspire to the tenants of the Ninja practice without resorting to violence. I admire the stealth and the awareness that everyone is motivated by different things and that by recognizing a person’s motivation, the Ninja gains an advantage. As a consultant, I desire every advantage I can get and like the Ninja, I am paid to get the job done and then I disappear, leaving my clients armed and ready to reap the benefits of my work (at least that is my goal anyway).

My target audience are those consultants on my team that are delivering SOA and/or integration solutions to their clients right now. My posts and all the content I provide is meant to assist and guide these consultants to deliver quality solutions. If you are challenged in this regard, read on and if not, in the immortal words of Gilda Radner from Saturday Night Live fame: “Never Mind”.

Enjoy,
Murray Laatsch
The SOA Integration Ninja

Want to see and hear the SOA Ninja, click here: http://www.youtube.com/watch?v=pIbTDLJIy6k