Controlled Agility

Modelling EAI

This is a recording of a journey I’ve planned for a long time. In EAI we have no common way of drawing pictures. Some people use a variety of UML artefacts, I’ve always been a proponent of simple rounded boxes and arrows. I’ve always been unhappy with the this ad-hoc approach to eai pictures, I needed something more. A long time ago (years) I chanced upon this document from the OMG. I read it and immediately didn’t understand it. I always planned to come back to it, really give it a go. The chance arrived the week before last – this is that story.

UML 4 EAI

A project I might be starting next week has some problems with integrations. Typical problems, inaccurate data, duplicate data, missing data, un-reconcilable data etc. They want us to come in, understand the problem with their current EAI setup, recommend a way forward. The guy “officially” running the show from our side is a big UML fan and wants me to draw lots of UML pictures so the client thinks we’re way smart. So I thought perfect, I’ll draw them within the EAI profile of the UML.

No tooling supports this profile. But since it’s a profile, I should be able to make the tools support me, shouldn’t I?  I went and downloaded Enterprise Architect from Sparx Systems, an Australian mob no less. I knew that they have support for profile development. Other tools may be more capable, but I knew of only this one.  And these guys allow me download a 30day trail – enough for my trialing purposes.

I started reading the document and quickly realised that uml4eai is a subclass of another UML profile, Flow Composition Model specification. The FCM spec is hard work. It deals with modelling components into flows, perfect I thought (and a little like BPEL as well, maybe?). It’s exactly what integration tools do, define some lower level services which you compose into flows. After reading the document and trying to make sense of it, I realised that I am no UML meta-modeller. Which is cool, I’m trying to implement a profile that’s a lower level of abstraction than FCM.

Back to the uml4eai spec. I read this specification trying to map it’s constructs to the handful of eai tools I’m familiar with. For the most part I’m successful. Messages, sources, targets, operators all more or less are mappable to toolsets I’ve used. 80% of what’s in the spec I can understand in terms of an implementation. Dissecting this document proves to me that I am definitely not a UML meta-modeller as I realised during the FCM spec.

After reading uml4eai and kind of understanding it, I thought I’d configure a profile in EA. I’ve never used EA before, finding it a bit too noisy, but what the heck, it’s cheap and people seem to really like it. With the uml4eai spec in hand and a print-out of the EA user guide discussing profile configuration in hand, I was away.

I tried to configure the profile for an EAILink. An EAILink is an association between two terminals. I understood this to be an association. I tried really hard to define this in EA. And I did, I had to subclass an Association but it looked like it worked. There’s a stack of OCL constraints you can put against this new thing, but I refrained from that for the moment.

Next thing I tried to profile was an EAITerminal. I couldn’t, from the specification understand what an EAITerminal was. Next!

EAIMessageParameter, which represents a message that is sent to an EAIOperation. It’s composed of a few parts, header, body, the usual suspects in this sort of thing. Whilst trying to implement this in EA, I tried to assign an icon to it. After all, the visualisation was what I’m after, more than the formal correctness of my picture. I couldn’t for the life of me figure out how to do it. My pictures looked like class diagrams with <<stereotypes>> under the class name. Not the look and feel I was after.

At this point, I was starting to realise that this diagramming standard was at an abstraction level that was too low, just like the UML. It occurred to me that I would have to define a solution in this ulm4eai drawing tool and then replicate the same thing in my eai tool of choice. It’s as if this notation is for a UML tool to then go and generate eai artefact stubs. Not really what I’m after.

My takeaways from this exercise where;

• Profile implementation in a tool requires a lot of UML knowledge.
• Tooling for profile development is quite average
• Uml4eai is an implementation notation, not a communication device.

BPMN

As part of trying to understand profile definition in EA, I came across their BPMN add-in. Initially I was quite excited by the pictures on the site as it looked like it would show me how to define icons for my profile – but alas, their BPMN profile is the same old <<stereotypes>> class diagram – very average.

But there is a good ending to this story. As part of the disappointing BPMN/EA experience I went to the BPMN site and read the documents that they have there. After reading all the documents, especially the one where it talks about mapping BPMN to a BPEL implementation, I’m hooked. This notation is pretty much exactly what I’m looking for. For my purposes it obsoletes the uml4eai ideas, which haven’t gained any traction in the industry anyway, and provides an easy to comprehend notation for business users.

By fluke, I think I’ve come across exactly the notation I need. The sub-process composability of the diagrams allow me to draw at any level of abstraction I choose, but allowing me to dive deeper if and when I want to. It also fits my rounded boxes and arrows diagramming preferences - excellent! Now I just have to find a tool that draws bpmn pictures that simple BA’s can add to their toolset.

Tags: uml, bpmn, eai, uml4eai, bpel

The "A" in SOA

In the next couple of days I'll post an analysis of Oracle's BPEL tool - after I do all the walk throughs. But first, to the amazing SEI architecture group. As you'll see in my BPEL analysis I tried to use the SEI's Architectural Quality Attributes. On their site I found an interesting paper that analyses SOA in terms of the Quality Attributes. These guys are -the- thought leaders when it comes to architecture. The paper itself is a bit of a mixed bag. There are some excellent parts and some less well developed parts. One of the nice management-friendly parts is at the end of the document where they use a red/yellow/green scorecard for SOA's impact on the Quality Attributes. None of this is rocket science - you could come up with this yourself - but you don't need to.

The paper quite clearly highlights where the soft bits of SOA are, from an architectural perspective. It is in this soft area where an architect can really hurt themselves. Testability of SOA solutions gets a big red light. As does auditability. Other attributes get warnings and some obvious ones such as evolvability, interoperability get green lights.

One thing that miffs me about this great resource, is that I can't subscribe to their "new at the SEI" content. I'd love for them to have a set of feeds which I could jack into and be au fait with the latest thinking from these guys.

tags:sei, atam, architecture, soa

bok bok bok - the chatter of chickens

Came across the Business Analyst BOK in my travels. Spent 3 or so hours with the draft to get a feel for what it is they're trying to do. I've been a BA in my past life - changing to development when I realised that I'd rather deliver business value than hold it up.

I was hoping that this document would right my misperceptions of BA's. But if anything, it seems to confirm my belief that BA's are really Requirements Analysts [and then testers]. If you take lean views of requirements, you'll tend to further discount the value of these Requirements Analysts as all they seem to be doing is adding to waste.

Overall this BOK suffers from the same thing other BOKs I've looked at do aswell. Basically, they never explain to me the risks or costs of the activities they talk about. Doing a literature study of best practices is fine, but doesn't help the practitioner make decisions on when to use what. What is the risk of not doing a logical data model - do I, as the project lead then want to take on that risk? What ends up happening is overzealous bokkers look to use every technique in the bok, and when they don't, they rip you up in the project retrospective because you didn't do it all. [sigh]

If you take out the sections here that properly belong in the PM and EA spaces, you aren't left with much that isn't just standard consulting skill. I wonder if the BABOK is a bit premature.

I can't wait to be served a BABOKDroid on one of my projects one day - it'll be just as much fun as getting a PMBOKdroid.

tags:babok

ps. Where's the section on testing? This is probably the most valuable role that BAs play in the SDLC and it isn't mentioned.