"Architecture is the continues quest for finding, keeping and sharing the perfect balance between philosphy and pragmatism through continuous evaluation of all stakes in blind justice by utilizing all available creativity and knowledge ."
Marcel van Eijkel -Eindhoven, 21 November 2008
Showing posts with label Wat is Architectuur. Show all posts
Showing posts with label Wat is Architectuur. Show all posts
Friday, November 21, 2008
Wednesday, June 18, 2008
The Business-IT-Gap has a face
With all the current hypes, just think about the Architecture, SOA and SaaS hype, you might think that agility, stability and interoperability are goals in itself. That they are specific magical ingredients recently discovered about to solve all IT related problems. This would not be an unlogical conclusion. After all, that's what is being promised you will need and get an agile business because that is what everybody needs.
Is it not? No, not at all!
In fact you just met the "Business-IT-Gap" in person. It might be the manager asking a developer for an application that should (obviously) be flexible and stable. Or it might be a sales person or consultant explaining a client that they really need to go for a SOA-solution for agility reasons. Either way you are actually physically facing a (e.g.: talking/listening to) person embodying the Business-IT-Gap.
Really? Explain!
The whole reason why the Business-IT-Gap exists is because managers have lacked to provide enough guidance about what kind of flexibility and interopability and the dagree of stability is that was needed (a responsibility now being hijacked by people calling themselves Architects).
Lacking this guidance resulted in systems lacking flexibility or the wrong kind of flexibility (thus maintainability) and interoperability. Moreover, because every developer has its own personal view on the type of flexibility needed, changes are that what is flexible in one application is fixed in another. Thus in fact lacking this guidance cannibalized the overall investments in flexibility. Believe me this is not theoretically speaking, this is what I see day in and out! I can't believe nobody else notices this...
So what should I do?
Of course, it's not only you. It's the whole branch! Developers should demand more guidance. Sales people and consultants should not propagate agility, interoperability and stability etc. "pur sang". They should explain that it is about Just Enough and about Just Right and that divers from situation to situation and company to company. You just can't and don't want to be totally agile either given a solution or given an total enterprise. It's about finding the right balance between what can be fixed and what should be flexible. Because flexibility comes with a big cost that can only be returned (roi) if it will be used sooner or later. Just think about architecting a house. Realizing all your dreams and whishes (read: requirements) in a totally agile structure would have you end up with something crazy like a hyper expensive stretchable balloon!
But now that you know, you can and should close the gap by asking the right questions and demanding a reasonable answer!
Happy closing the gap!
Is it not? No, not at all!
In fact you just met the "Business-IT-Gap" in person. It might be the manager asking a developer for an application that should (obviously) be flexible and stable. Or it might be a sales person or consultant explaining a client that they really need to go for a SOA-solution for agility reasons. Either way you are actually physically facing a (e.g.: talking/listening to) person embodying the Business-IT-Gap.
Really? Explain!
The whole reason why the Business-IT-Gap exists is because managers have lacked to provide enough guidance about what kind of flexibility and interopability and the dagree of stability is that was needed (a responsibility now being hijacked by people calling themselves Architects).
Lacking this guidance resulted in systems lacking flexibility or the wrong kind of flexibility (thus maintainability) and interoperability. Moreover, because every developer has its own personal view on the type of flexibility needed, changes are that what is flexible in one application is fixed in another. Thus in fact lacking this guidance cannibalized the overall investments in flexibility. Believe me this is not theoretically speaking, this is what I see day in and out! I can't believe nobody else notices this...
So what should I do?
Of course, it's not only you. It's the whole branch! Developers should demand more guidance. Sales people and consultants should not propagate agility, interoperability and stability etc. "pur sang". They should explain that it is about Just Enough and about Just Right and that divers from situation to situation and company to company. You just can't and don't want to be totally agile either given a solution or given an total enterprise. It's about finding the right balance between what can be fixed and what should be flexible. Because flexibility comes with a big cost that can only be returned (roi) if it will be used sooner or later. Just think about architecting a house. Realizing all your dreams and whishes (read: requirements) in a totally agile structure would have you end up with something crazy like a hyper expensive stretchable balloon!
But now that you know, you can and should close the gap by asking the right questions and demanding a reasonable answer!
Happy closing the gap!
Wednesday, April 2, 2008
Architectuur is de oplossing, maar wat was het probleem?
Als Architect kom je maar al te vaak in een situatie dat je moet uitleggen wat een Architect doet en wat de voordelen van Architectuur zijn.
Als je, net als ik, hiervoor een presentatie mag maken dan komt de volgende presentatie van het IMN (Informatie Management Nederland) je vast goed van pas!
De presentatie is in twee delen opgebouwd:
- Deel 1 geeft de algemene lijn van de IMN visie op architectuur-toepassing weer
- Deel 2 gaat concreet in op het gebruiken van de IMN-visie bij het toepassen van architectuur voor een specifieke probleemsituatie
Klik hier voor de PowerPoint.
Als je, net als ik, hiervoor een presentatie mag maken dan komt de volgende presentatie van het IMN (Informatie Management Nederland) je vast goed van pas!
De presentatie is in twee delen opgebouwd:
- Deel 1 geeft de algemene lijn van de IMN visie op architectuur-toepassing weer
- Deel 2 gaat concreet in op het gebruiken van de IMN-visie bij het toepassen van architectuur voor een specifieke probleemsituatie
Klik hier voor de PowerPoint.
Subscribe to:
Posts (Atom)
Posts
