Every once in a while I find a little gem on the Internet: some piece of information that’s so briliant, you should treasure it!
Here is such a gem: it’s a presentation by someone called Alan S. Koch and it compares PMBOK with the Agile Manifesto.
PMBOK is the Body of Knowledge for Project Manager… at least that’s what PMI claims.
The Agile Manifesto is the definition of what being agile is all about.
I know it’s a rather old article but here’s what IBM thinks of the Pace of Change in the Java EE specifications (or should I say “the Pace of Change in their WebSphere product line”): “the majority type [of customers] is telling us, ‘You’re shipping things to us so quickly and comprehensively that we’re having a hard time consuming it”.
So, IBM decided they’re not going to ship a Java EE 5 edition of their Application Server until 2008.
But I wonder if it’s such a good idea to wait another year. I see that a lot of customers are already experimenting with Java EE 5. Especially because Java EE 5 makes Java development on the Enterprise Platform so much easier than the previous versions.
IBM customers, who want to try out Java EE 5, are now forced to use non IBM software for their experiments. Perhaps they’ll like the competition so much, that they will not return to IBM when they finally decide to finally release the Java EE 5 edition.
So, there’s also a downside to staying too long in a ”Status Quo“… People sometimes want to change and if you don’t let them, you might disappoint them…
A Realistic Visionair once told me: “The pace of adoption must remain higher than the pace of change.”
Here’s a nice model that supports that statement: the Satir Change Model. It describes five stages that you go through during a change: (1) Late Status Quo, (2) Resistance, (3) Chaos, (4) Integration and finally (5) New Status Quo.
Now, Merriam-Webster’s Online Dictionary defines “adoption” as “the act of adopting”; “to adopt” is defined as “to accept formally and put into effect”.
And I believe you can only start talking about “adoption” in the last two phases (Integration and New Status Quo) of Satir’s Change Model. As its only then that “the members [of the group undergoing a change process] discover a transforming idea that shows how the foreign element can benefit them”.
If you study Satir’s model, you see that the best point to start a new change process is in the New Status Quo. So, only when the previous change process has been fully adopted (past tense) and not just when it’s still being adopted (still being put into effect)…
If you don’t wait until the New Status Quo before you start a new change process, you’ll only introduce more chaos and cause less productivity, perhaps to the point where you cannot handle it any more. And it will only take longer until you reach a new Status Quo.
If only we always had so much time…
These days there are only two reasons why I read books: (1) to educate myself and (2) to be able to advise others what books to read.
I read Essential Software Architecture
And I can really recommend it to anyone who wants to know what Software Architecture is all about these days.
Not only does it give a great overview of the basic knowledge you should have as a Software Architect (Quality Attributes, Middleware Technologies, SOA, MDA, …), it also contains a lot of references to other great sources of knowledge. A lot of the books Ian refers to (such as Patterns of Enterprise Application Architecture
The chapter on Software Product Lines (written by a guest author) was a bit disappointing to me, but that still gives you 14 other very interesting chapters.
In fact, at AE, we liked it so much, that we added it to our welcome pack you receive when you start as a Technical Architect. So if you’d like a free copy! Sign up! :icon_wink:
In my previous post, I discusses the idea that the actions that a human being using a software, could be considered (modeled) as a component in that piece of software.
Here’s basically the same idea, but from IBM and instead of a component implementation, they consider humans as service implementation.
“Human-based
Web services provide the ability to transparently include people as the
service implementations in arbitrary service-oriented applications.”
What I don’t like about the “Human Service” is that you group operations according to their implementation instead of functionality. Additionally, when an operation no longer requires human “intereference” it is (re)moved from the human service and possibly added to another service… isn’t that strange?
I’d like to stick to the idea that all operations on a service are about the same functionality, not the same implementation.