Trying to Hit the Nail on the Head

Something to think about: should Architecture Management be a new ITIL process and should the services offered by Enterprise Architects have SLA’s?
Something to think about: should Architecture Management be a new ITIL process and should the services offered by Enterprise Architects have SLA’s?

In IT it looks as if it’s “innovate, or be doomed”.

Here’s some reasons why a company could need innovation:

• Because the vendors are going to stop supporting the old stuff. (See BS2000 )
• Because you’re people are getting too old and the young folks don’t now the old stuff any more. (See COBOL.)
• Because the new thing will be so much better/easier/faster/…  (but sometimes it isn’t) (See C# )
• Because you’re people want to learn something new (See Java )
• Because your clients are asking for innovation (because of one of the above)

Why do you need innovation?

In an attempt to clean up my laptop, I found these two programs which I created more than 7 years ago.

• RESIST helps you in decoding the color codes on resistors.
• SAMR, which stands for Simple Automatic MP3 Renamer, does exactly that: it can (batch) rename MP3. Should still work, but better to use the “COPY” option, so that you don’t loose your MP3s in case something goes wrong.

I’ve attached them, as they were originally packaged, but the URL and my email address are no longer valid.

By the way, no use asking for updates, fixes, … as I haven’t found the source code back yet… no surprises there… :icon_wink:

“We support Business Agility” is one of sentences that a lot of marketing boys in the software world use.
To give you a feeling of how often: the query “business agility” OR “agile business” gives you about 992.000 hits on Google. That’s roughly 50.000 more hits than one of our Belgian symbols:  the Atomium. And more than twice the amount of hits for that other Belgian symbol Manneken Pis. (Luckily we still have beer and French Fries, which should have been called Belgian Fries, but that’s an entirely different story.)

If you listen to the marketing boys, promoting Business Agility, they’re usually trying to convince you that the processes of your business, their business, anyones business, … changes a lot.
It’s as if almost every week or so, two steps in your business process change places.
And the software of your business, … should be able to adapt to those changes as quickly and cheep as possible.
And before you know it, they’re talking about SOA… because that’s the way to support Business Agility.

Now, I agree that if you’re business processes change a lot, SO(A) might come in handy. Because, if you implement you’re Service Oriented software correctly, you’re business processes should be very easy to find in your software. And ideally, the steps in your business processes, should be (operations on) software services. So, when two business process steps change order, with an SOA, it’s should be easy/easier to implement these changes in the software as well.

But, to me, being agile is more than just being able to change the order in which you do things. It should also be very easy to change what you are doing; to change what is done in a specific step of your business process.
Again, SO(A), can help you a lot: SOA makes it easy to locate the step that changed in your software… But, this kind of agility doesn’t stop there. If the (operations of) your software services are not well designed, it might still be very diffictult to find out what needs to change. And a good design in this case means, means a design that supports business agility.

Still following?

I guess what I’m trying to say, is that there’s more to Business Agility than reshuffling business process steps. And that your entire code should reflect your business… true Business IT Alignment (208.000 hits)

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 by Ian Gordon for the second reason.
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 by Martin Fowler), I can also recommend, which makes Essential Software Architecture really a great starting point.

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.

Because of “new” ideas such as workflow and BPEL our ways of identifying and analyzing automation needs have changed. More and more, we do no longer start at what a user needs, but at what needs to be done; we start analyzing the business processes first. And that’s a really good thing.

Now, when we have our business processes, brave people dare to say that the y are in fact the requirements for the software that needs to be created. Very courageous even say, that they define – or at least inspire the design of – the (software) services that will combine into the software. (The reason for this is, that it’ll make your life as a software designer a lot easier to keep in pace whenever the business processes change.)

But when we “really” start designing/analyzing that part of the business process that needs to be automated (or supported by software), it’s asif we take a step back and start thinking: now, how would a user want to do this… and we recombine everything again, even if this means that means making the underlaying services less functionally coherent.

Now, let’s think of humans as just a “biological” software component implementation.
Humans interact with software using a very specific protocol, which translates incoming data to visual stimuli (the GUI) and keyboard and mouse actions to outgoing data.

The model that mostely is used (not the model I present here), has too many limitations. The entire webbased/thin clients wave for example, uses a pull model, where data is only shown to the user if the data is pulled from the backend; in most applications, there is no push. However, in real live applications, there often is a need for it… and it’s better supported by a mental model that looks at humans as components as components do not only have required interfaces (with operations that must be provided by another part of the system), they also have provided interfaces (that can be called by other parts of the system).

More and more human interventions will get automated. It might not look as a happy future, but rule engines could replace some if not a lot of the “manual” human jobs done today. Replacing these tasks with a piece of software will be a lot easier, if the interaction was embedded in component.

…

I’m sure that some people might be offended by the ideas in this post (especially the part about replacing a person with a rule engine), but I’m going to give it some more thought to see where I could end up with this train of thought. And I’m also going to investigate on how other protocols are formally specified. Perhaps that might give me some idea on how to specify the computer-human interaction more precisely.