Brandon Werner

If you don’t read Susan Cramm’s articles at HBR, you should. It has great stuff that deals with the intersection of technology and business in brutally honest fashion. Cramm has been both a CIO and CFO, so she’s seen it from both sides and gives a honest and direct point of view from the business space. This particular podcast from the Harvard Business Review talks about these frustrations in general terms. We should figure out how perhaps our behavior and processes can lead to this frustration (I can think of a few)

http://discussionleader.hbsp.com/cramm/2008/06/8-things-we-hate-about-it.html

Overview:

1. IT Limits Managers’ Authority You bring in 10% of the company’s revenue but can’t authorize a $100,000 project if it requires IT. Furthermore, IT’s bureaucratic governance process rivals the tax code in complexity and inhibits rather than promotes innovation.
2. They’re Missing Adult Supervision The CIO is impressive, but totally unavailable. So the next best option is your IT “relationship manager" who’s a few clicks down the evolutionary scale and doesn’t have the breadth of expertise to truly act as a trusted IT advisor to senior business executives.
3. They’re Financial Extortionists When was the last time there wasn’t some emergency in IT (e.g. Y2K, SOX, HIPAA) that requires a zillion dollars? Compound this with the lack of visibility into how IT spends non-project dollars and it makes you want to become a technology vendor to cash in on the booty.
4. Their Projects Never End In-process projects are always 90% done. "Completed" projects don’t have agreed to functionality, and the team that promises to deliver missing functionality in future phases are always mysteriously missing-in-action.
5. The Help Desk is Helpless When glitches emerge, you are become a technology pauper, going door-to-door begging for help while functional specialists defend the reliability of their piece of the byzantine infrastructure.
6. They Let Outsourcers Run Amok You know that outsourcing wasn’t really IT’s idea, but you blame them when you’re trying to communicate with external “service” providers that lack even a basic understanding of your business. It’s like trying to teach calculus to a 4 year old.
7. IT is Stocked with Out-of-Date Geeks It’s not good when you learn about social networking from your 12-year old at home while IT is still trying to cope with email. Then, when you try to brainstorm with IT about how to apply new technology, you get paternalistic responses akin to the look that parents give their children when they play dress up.
8. IT Never Has Good News No matter how much you spend and how hard you work, you never have anything to celebrate and little to look forward to as the promise of technology seems perpetually beyond your reach.

What do you think of this list? Is it out of line or hit uncomfortably close to home?

This is a presentation I created to describe how SDOs can be used in the Insurance enterprise space to provide sanity in the large and diverse messages. These are increasingly being passed around as Business Objects in a Domain architecture as companies move their old object patterns to a service based approach (I refer to it as servitized business objects).

If you are looking for my particular experience on how SDOs and the IBM EMF framework that contains them works against the large ACORD schema, you can find my critique of Websphere Process Server and ACORD here and the SDO design pattern plugin I wrote for Rational Software Architect here.

You can download the slideshow here.

I seem to be visiting a lot of my prior entries from 2005, but a while back I wrote about an experience I had meeting an old IBM programmer at the local Catholic store. She was female, which seemed like a trail-blazing thing to have been working in the heavily male dominated technology industry in the 1950s. Her story, and her eagerness to share with me, led me to write my experiences with gurus in my life, entitled In The Presence of A Guru (On Catholicism, VAX/VMS and Geek Culture). I still feel profoundly stupid for not having spent more time with her, as it was obvious she wanted to share her story. I will regret it for the rest of my life, not just because of what the exchange could have done for my understanding, but more refusing my obligation, the obligation we all have, to listen to and carry on the mythology and history of our elders. I am afraid that mythology may be vanishing, and none of us are listening.

I thought about this again when I stumbled upon a new blog from Dan Weinred as linked from Lemonodor. His career in Computer Science and his contributions certainly qualifies him as a Guru.

His essays so far are a treasure trove of information and computer science archeology. One of my favorites is called The Technology and Business of ObjectStore, where he recounts taking his ObjectStore technology to Microsoft and Bill Gates as well as Steve Jobs. The reaction of both icons demonstrates humorously their approach even now:

When the new Windows technology (which was OS/2 at the time; IBM and Microsoft were still working together on it) came out, it was crucial for us that it be able to support memory mapping. Dave Stryker and Tom Atwood, flew out to meet with Bill Gates in September of 1989. Dave Stryker recalls: “We originally had a 45-minute appointment, but Gates extended the meeting to a couple of hours, and called in Dave Cutler [the architect of OS/2]. At Tom’s urging, we told Gates and Cutler everything they wanted to know about ObjectStore. Gates was complimentary of the Object Design approach, but said, in a nice enough way, that if the Microsoft Empire ever needed such a thing, they would build it themselves. Still, Gates told Cutler to make sure that the OS/2 equivalent to mmap was powerful enough to run ObjectStore, and there were some changes made to make it so.” Later, this OS/2 technology turned into Windows NT. Dave Moon adds that it turned to have a bug: it doesn’t free up disk space when it ought to. For some reason Microsoft hasn’t fixed this, even after many years. We found a way around it.)

Speaking of industry luminaries, we also met with Steve Jobs when he was at NeXT, and Jobs made a big announcement praising our technology, which resulted in a nice press release. There was some discussion that NeXT might buy Object Design, but that never went anywhere.

This type of history is fascinating and important. There have been efforts to capture this knowledge, such as Fokelore.org and ACM’s excellent ACM History Committee trying to archive CS knowledge, but their efforts so far is approaching it the wrong way. It’s getting the stories, while these people are still alive and can tell them, that is important. Much of it will not be academic or well checked, but that is missing the point. It’s the mythology as well as the history of these pioneers in the 1930s - 1970s that we should be after. We’ve already lost Jeff Raskin, Adam Osborne and others.

If we do not do this, their legacy and our history as a profession, one that has changed the world as much as any other in human history, will be lost forever.

Below is an interactive slideshow of my talk given at the IBM Rational conference in 2007 entitled “From Legacy to Service-Oriented Architecture: The Strategic Importance of Services in the Insurance Industry”.

Synopsis: The insurance industry is one of the most complicated industries to manage from an IT perspective. Its complex and highly regulated business rules, as well as its early adoption of mainframes in the 80s and 90s, has led to a significant hurdle in moving existing infrastructures to a Service-Oriented Architecture (SOA). This session shows how the use of IBM Rational tools and IBM(R) Websphere(R) Process Server can free the industry from the complexities of implementing state specific compliance and business workflows through modeling and mediation flows.

This is a presentation I created to describe how SDOs can be used in the Insurance enterprise space to provide sanity in the large and diverse messages. These are increasingly being passed around as Business Objects in a Domain architecture as companies move their old object patterns to a service based approach (I refer to it as servitized business objects).

If you are looking for my particular experience on how SDOs and the IBM EMF framework that contains them works against the large ACORD schema, you can find my critique of Websphere Process Server and ACORD here and the SDO design pattern plugin I wrote for Rational Software Architect here.

Click the image to view this presentation interactively.

You may get the full version in Quicktime Movie format or Microsoft Powerpoint format.

I get a lot of emails about my critique of IBM’s Websphere Process Server, mostly along the lines of this email:

I’ve sent this email to you a couple of months back but didn’t get any reply. just thought would try my luck again…

we’ve made some progress with WPS and identified what areas are less risky so we can use at least some of the product features. we’re now building a prototype that uses mostly human tasks and some processes wrapped around them and we expose this all via webservices. there’s some pain around versioning, BPEDB queries, security, etc but at least we’re making a progress and early indicators seem to be on a positive side. we have had a couple of IBMers on site for a week and they helped us somewhat to rejig the design and focus on the features that seem to work and would add most value

still would be extremely interested to find out if you have done more with the product since you blogged about it

Well, obviously for competitive and disclosure reasons I can’t spill the beans on where my current employer is, what they are doing or why they are doing it. With those hand-cuffs in full public display, I will effort a more general entry about the state of affairs of this odd stack IBM has built.

In order to understand IBM’s approach to Websphere Process Server, you have to understand SCA/SDO, the unholy combination that seems to be driving the SOA mythology as of late.

About SDOs

There are currently three different implementations of the SDO spec, including Apache’s Tuscany (the one I’m cheering for), IBM’s from their EMF project for Eclipse and the interesting EclipseLink from Oracle and Interface21 (when those two get in a room together you should listen). EclipseLink is more of a consequence of combining SDOs and JPA, however.

I’m extremely excited about SDOs in general, to the point that sometimes I sit on my deck and dream about them. I even write presentations about their architectural implications. SDOs are awesome things.

They are, in essence, disconnected DataGraphs of DataObjects from some source. This source could be relational databases, entity EJB components, JCA, XML pages, Web services, or a combination of them all.

They can be acted upon and changed, updated and deleted, transformed, even serialized and sent to other objects and then connected back to the original data source with a ChangeSummary() to boot. For a more detailed understanding, check out IBM’s Introduction To Service Data Objects.

This is what they do in a nutshell:

1) You have data in any form from anything: Databases, XML, text, anything (or a combination of them).
2) You feed that data in to a Service Data Object.
3) Things can get pretty loose in there, so you can impose an XSD to define the types or just create the model on your own as you feed data in.
4) You disconnect the SDO from it’s source.

SIDEBAR: Last year I wrote a design pattern for SDOs in Eclipse’s UML2 framework that you can import in to Rational Software Architect.

Now you can do anything with this thing. Change the data inside, add more things to it, remove things from it, serialize it and send it across the wire, query the data inside of it, introspect it, combine it with JPA and tell it to save itself away from it’s source, anything.

Imagine the implications.

Design Strategy: Using SDOs with POJOs

No longer do objects have to have a strong contract, or any contract at all besides taking a type of DataObject. Your Business Objects can introspect the object itself to see if there is data inside of the DataObject it requires to do a task, do work on your behalf, update the DataObject’s DataGraph with new information (or replace existing information), and pass that SDO right back. The calling object can ask for a ChangeSummary() to see what occured to the data in that object, act on that data, and send it right along again to another object. When you are finished passing it around, it can immediately turn back in to the XML or database row it was loaded from.

Your Business Objects can change, the data inside your DataObject can change, or be a totally different DataObject all together. As long as the Business Object can query to see if the data it cares about is in there nothing about the contracts between your objects need change. Further, because of the API that comes with the SDO spec, your object doesn’t really need to know anything about the DataObject it’s feeding data into or getting data from. It can work with the part of the DataGraph it needs in a hands-off way and be done with it.

Think of it from a automobile insurance Use Case:

Say that you had a document based webservice that took an automotive insurance policy. This automotive policy would have an XSD that ensured it contained the data necessary for a complete policy. That XML document, once received, would be loaded in to an SDO with the XSD which would “strongly type” the data inside the DataObject that was generated.

Now, imagine this policy was sent to the webservice for a claim to be issued. You could pass this new SDO in to a “claims” system to be processed. The contract for the Claims system is just an SDO (type DataObject). The Claims system would do a simple XPath query, or do a get() on some data that it expected any DataObject that would come in to the system to have (remember, the data inside does have querable types because it was loaded with an XSD). Technically, it could even introspect the SDO DataGraph to find the data it needed. Whatever.

It would probably want to get Customer Information, Units Insured, ect. It would then do it’s own thing looking up the coverages, the limits and going about process to start a claim.

After processing, it could then append it’s update to the SDO by inserting data back in to the DataObject. The DataObject would then be sent back to the webservice, which would change the SDO back in to the XML document (again, the XSD ensures compliance) and sent back to the ESB or some other thing, but now with information on the claim that was created for it.

Now, remember that the Claims system doesn’t really know or care that the SDO is a policy. In fact, the SDO really has no type at all. You could have policy information, a recipe for Apple Pie and an iTunes playlist in the SDO. As long as the Claims system can get the right data from the SDO, it’ll work.

You could just as easily send the Claims system an SDO that only has the data necessary for issuing a claim. You could also change the Claim system so that it requires more information from the SDO, or writes additional information to the SDO (say requirements change).

None of this need impact the contract or the SDO that gets sent to the system.

So essentially, this is what an SDOs used with POJOs alone gives us:

• Objects are loosely coupled
• Object’s data can be discovered at runtime through query
• Object’s contracts are data based, no types or tightly binding interfaces
• Object is protected from contract and interface changes in system
• Objects can be placed anywhere - maximum reuse
• Object can modify it’s types and data structure during runtime
• Object has no restriction on the data it can share
• Object is decoupled from the format and source the data came from
• Object automatically can roll back to the previous data state or act on changes

This is just the impact SDOs have on sharing data between objects. SDOs have much more up their sleeves, including transformations and mapping.

It’s easy to see how this would fit in nicely to the theory of an SOA architecture. If you could just push around self-contained datagraphs of dataobjects, disconnected for their source, and transform them, map them together or change them in to other types of data, a lot of the complexity of dealing with data in an SOA would be solved… or at least abstracted.

SDOs and Websphere Process Server

It’s helpful to keep in mind that all workflow engines (WPS, JBoss jBPM, BlueSpring’s BPM) is a movement of the business logic and process flow from inside the code to outside, and that can only mean better flexibility for organizations going forward, even if current architecture design patterns regarding Business Objects have to change and give up their power or expose it more freely for orchestration (Fowler be damned).

The most intriguing thing about WPS, or any modern workflow engine, is the idea of visually managing the flow and business logic of services in an SOA. WPS promises to separate this orchestration from any code (save the code that it generates) and mix in human tasks to boot.

Workflow tools can be great when you have an Enterpise Service Bus or other solution where you have data flows coming at you from different technologies and different protocols that you want to feed in to a workflow. When you pull in a webservice or other Type that WPS supports in to it’s grahical tool, Websphere Integration Developer, it essentially reverses these data streams or objects in to strong types that are represented visually so that you have common base on which you can orchestrate, transform, and map the data between the various other imported flows. It’s easy to see how it leverages SDOs to do this, as it’s essentially what SDOs are best at. Mapping between these things and orchestrating them are easier if you have an abstract representation of the service or object.

The idea of building an entire enterprise from the ground up with this product is intriguing. However, I doubt that any project already in motion could manage to migrate from business logic in code to business logic in a product without significant rework, and the consultants specializing in WPS (and they are starting to emerge) seem to only have experience starting from scratch and in projects with human interaction. Regardless, this orchestration is most likely where WPS has the most benefit. It’s idea of transformation and consuming of the documents in the mediation itself is where things break down.

In Websphere Process Server, IBM essentially decided to use SDOs to parse and transform any data that comes in to their system. They coupled this with their previous Websphere Business Integrator product (WBI) for business orchestration of the processes that use these SDOs, stapled on an ESB implentation, stuck a feather in it’s cap and called it Maccaroni.

A product being a webservice de-seriailizer, data mapper and transformer, workflow tool and process manager is what ultimately makes Websphere Process Server the strage beast it is, and is also a major source of it’s problems.

In the work I’ve have done with WPS from a purely transformation and webservice flow standpoint, I’ve have found it to be slow but it works. There has been significant problems with the limited amount of flexibility WPS has in processing XML, managing messages and executing processes. IBM pitches that with WPS/WID business analyst or architects would be the ones that would do the mapping and process orchestration using visual tools. Often, however, we have been forced to fall down past the level of abstraction that WPS provides down to the Java code itself, which that is a sign of, if not failure, then immaturity.

Also, Websphere Process Server’s IDE where this mapping takes place visually, Websphere Integration Developer, is (since it is built on top of the Rational/Eclipse platform) hard for non-programmers to grasp; the idea of having to switch perspectives in Eclipse is foreign and unhelpful.

Ye Ol’ Impedance Mismatch

Unfortunately, even when you do go down to the Java level, things aren’t easy.

There are many times that what a WSDL specifies (compliant XML mind you) as a certain “type” and what “type” WPS renders for it are totally incompatible. For XSD:ANYTYPE, it dies flat out. However, so does any WSDL2Java tool. To combat this, code that was using the Collections framework has to be migrated to fixed length arrays so that WPS can interpret the output, as it sees any List as “AnyType”

Certainly, this type mis-match is experienced whenever one jumps from objects to documents in representing data (JSON anyone?), but that just points to the enormity of the problem WPS is trying to solve, and how trying to reverse XSDs without developer intervention is painful and filled with problems.

My Update

So, my update is that it still is not delivering on it’s promises, yet. However, I have heard from IBM that version 7, based off the Rational 7 (Eclipse 3.2) platform should be out in August / September.

I hope the reply was worth the wait.

I have been asked to present my work: “The Future of ACORD: Using Data Standards In The Semantic Web” at the Insurance Industry’s major conference ACORD-LOMA Insurance Systems Forum from May 20th - 22nd at the Dolphin Resort at Disney World. Since Microsoft and IBM are platnum sponsers, I’m expecting lots of free stuff At least, more than you get speaking at the Rational Conference.

I have included the detailed snippet from the brochure below, and more information about when I’m scheduled should appear on the website after February 2nd when I deliver all my media information (my head shots from junior high apparently don’t cut it anymore)

My primary thesis is how to use the language in which we communicate, XML (here ACORD standard) and apply meta-data to enable us to gain insight and increase both human and machine understanding of the data we have, essentially helping us make better decisions. It’s easy to see how a system knowing what a policy or a named-insured is beyond just an XML tag can benefit decision making systems including competative rating and data mining for risk patterns in insurance. All of this is based off of using RDF and Ontologies (here developed for insurance) to make relationships between data. Imagine how much more valuable a data warehousing operation would be with this solution.

I think you’ll like it and I hope you can make it.

My question to you is: Do you think the industry is ready, having just now got up to speed with webservices and Service Oriented Architecture, to apply meta-data to our language? Although the benefits of making the semantic leap are real, is it realisitic in the near future?

My Presentation Brochure Detail Snippet

XML, as a describer and standardization of data and datatypes, are changing as we move in to a future where humans won’t be consuming data as much as other computers will. The Semantic web is about metadata, or “data about data” that tells computers what type of data it is, and it’s context. It is about a language for recording how the data relates to real world objects. This allows a person, or a machine, to start off in one database, and then move through an unending set of databases which are connected not by wires but by being about the same thing.

For the insurance industry, this transformation can bring incredible advances and solutions to the problems we are experiencing as an industry that XML and webservices alone can’t solve, including managing large amounts of data and customer information. In the Semantic Web, for instance, we can know what products may interest a customer through relationships built from their CLUE reports and their preferences or send self-describing products to agents without any upfront setup. Most importantly, it can be used in data warehousing applications to allow insurance companies to create their own meaning from their customer data for better rating by deploying reasoning systems to determine what risks are related to what datasets deeper than ever before.

ACORD standards will play the lead in this, and companies that are adopting ACORD standards in managing their business communications now, especially using ACORD in their webservices, will have a lead in this advancement. ACORD can become “richer” when paired with RDF documents that not only enforce the standards, but describe them as well.

In my presentation, I will demonstrate the future value of deploying these reasoning systems, demonstrate the work I’ve done in developing reasoning systems for ACORD formatted data, demonstrate a sample using Firefox and MIT’s Piggy Bank plug-in (http://simile.mit.edu/piggy-bank/ ) of a future ACORD standard based website that will show a customer, the products they may like and the best rate; all from self-describing meta-data and without any code (only the data itself)

I work with MIT’s Semantic Web SIMILE (http://simile.mit.edu/) project as well as invented and run the opensource cl-semantic project (http://common-lisp.net/project/cl-semantic/ ) that uses Lisp to discover relationships between data for automatic processing and the realization of patterns, geared specifically towards insurance and other probability based businesses. I have also been involved in research creating a RDF version of the ACORD standards (the subset of Surety) to allow ACORD standards to be used in a Semantic Web demonstration. I am also an ACORD voting member of the Casualty/Surety working group and sub-groups underneath. I am well known in the industry for my work, and you can browse my referred and non-referred research papers from my website (http://www.brandonwerner.com).

As the year draws to a close, I realize I haven’t been conference jumping as much as I use to, but did want to draw attention to a few places I will be presenting sessions for. If you are attending, be sure to say hello. More information on times when it becomes available.

ACORD LOMA Insurance Systems Forum
May 20 - 22nd 2007
Lake Buena Vista, FL
My Session: Future of ACORD: Using Data Standards In The Semantic Web

IBM Rational Software Development Conference 2007
10-14 Jun 2007
Orlando, FL
My Session: Websphere Process Server and SOA For Insurance