Astah

I found out a fantastic UML Tool for the iPad: Astah. It's graphic is fantastic, crystal clear, easy to use, with PNG and XMI export by email capability. The class modelling is almost complete, it, only relational entity classe is missing but it's the only bit that I can find. I suggest all the iPad UML addicted users to download it.
It's very usable, effective, and very professional in meeting where you can quicly nail down someconcepts in UML and send the diagram with others.
I was amazed by finding this UML master piece in the iPad. My mind is already thinking about possibile extension such as Use Cases that would be very effective or requirement catalogue.

Class Diagram with Astah for iPad

The guys doing this software are from Japan, I hope the best for them.

UML Rorschach Diagram!

I think I will make a submission to the OMG, a new diagram is needed in the forthcoming 4v of UML: the Rorschach Diagram! Like a Rorschach Test, you can put boxes an lines randomly in the diagram and let users perceive the semantics they want. Very useful to create UML models quickly not caring about the semantics that will be created by readers. They will also see what they want to see, and usually it's the solution they seek for their problems.

Why modelling when you can draw on a white board

I came across this pretty fancy blogger that states that it's better do draw on a white boards "A "plain old whiteboard (POW)" is my favorite modeling tool". It then says that since these might useful to others they can be captured in a picture "We took the photo because we were afraid that we’d lose the valuable information that it contains". It's so valuable that it deserves a picture but not enought to be modeller in a tool.
Finally he shows that in order to clean the picture from the nasty reflection he used a painting program to manually remove the spot.
Another guy in a forum states "...but I use white boards. Keep many of them around so that they don't have to be erased".

No comment here. Let's say what will the future tell us.

Painting processes

While digging the Internet I went through a blog with a discussion about Compensations in BPMN. This is a clear description of what I consider an anti-pattern in modelling. These persons are disguising if the given example is corrent for modelling compensation in credit card processing. There are replies in the thread that propose alternative models and explain with plenty of details why a model is wrong and why another one is correct. It's mentioned for example that there is not an undo, that the logic is wrong because one entity is reached after another.
The tebate is interesting at first, except that it lacks a key concept: the model has never been exectuted actually! Essentially in the blog people argue the correctness using hipotesys but no one has ever had the idea of executing it, "let gives some input and see how it behaves". As we have done for decades with code that implements algoriths like binary seach, bubble sost, linked list, we'd execute it in order to test it, and to find  which inputs break the algorithm and then we can try to fix it and propose alternatives.
This is a nice demonstration IMO that modelling is still treated essentially like painting boxes and lines in a canvas. But hey, BPMN is a computable specification with well defined behaviours, we might be able now execute it in Intalio, JBoss, BizAgi for example like any other code. If it behaves has planned that it's correct, othervise not.
After all, a model is a code and a code is a model, we shall treat it in the same way.

Business Execution Environment, BEE

IT is assuming the role of an enabler of the business. Without IT it's not possible not only to run a business, even if not related to the Internet or eCommerce; let's think in the Energy, the Utility sectors, Post, Government... This is not just because data is stored and retrieved or because there's a web site giving information, it's because the entire strategy and planning and governance is modelled and executed in the IT systems: pricing and forecast are implemented in applications, but we still miss the concept that IT "is" the business, and most of us thinks of IT in the same old fashion, or with little improvements.
I strongly believe that it's unfair to keep saying "aligning IT with the business"; this gives the false perception that business is and will run faster than IT, that a decoupling is essentially unavoidable, as it were a customer-supplier relationship. What I perceive as a message with this stereotyped sentence is that the IT has just to support the business at a faster pace. This is seen in the so now fancy "agile approach" in software development, the effect is that we give the false idea that it's all about "faster developmnent" or "faster features release". The focus in not in development but rather in maintenance, we must be aware that an application is never finished, it's continuously evolving, there is not a final deployment; the very famous RUP diagram with the phases' efforts depicted as curves, should never ends. There is no distinction between development and maintenance.
There shall be an IT environment able to host and run the entire governance of an organization, with multi level configuration capabilities in oder to allow non IT people to affect the business, to change it's strategies via an update in a business models, pricing schema. boundary values, rules. Another layer shall be able to assemble new business processes without actual development but rather using predefined services and data models. The organization shall govern on top of a Business Execution Environment, the business is in the IT and the IT hosts it, there is no gap at all because nowaday there is less and less way to influence the business without moving bits and bytes in a wire. I've seen organization struggling with post-it or spreadsheets attached via email to implement the business in a way the IT was not able yet to support. The complexity in the business and the speed at which this happen is increasing at a rate where almost no one can conceive the impacts in doing a manual change.
We shall consider the idea of a Business Execution Environment (BBE) where the business is governed and managed. This requires proper Architectural strategies and modelling techniques beause IT is still plenty of the same old multidimensional issues such as: data storage, interoperability, legacy apps, middleware, data types, technical compatibility issues, transactions, programming languages, execution platform, tools, performance, security, ids, standardization and people of course ;)