My father bought one of the first 100 TRS-80 computers ever made and at the age of 11 I was fluent in assembler. By the time I finished high school, I could program in 14 languages. I've found other people who have similar backgrounds - and in almost every case they share a similar trait: the ability to recognize a disruptive technology.
In my career, I've made a few "early calls":
1985 - Windows 1.0
1991 - Visual Basic 1.0
1993 - PowerBuilder 2.0
1995 - Java
1997 - XML
2002 - BPEL
and now,
2005 - SDM
It's that big. It's right - and it will change our profession.
Thursday, April 28, 2005
Sunday, April 24, 2005
Canned Architecture
Several things in the Agile world has always bothered me. The one I'd like to point out today is the concept known as BDUF. The summary of BDUF is:
Over the years I've noticed that the closer one is to the code, the less they tend to distinguish between architecture and design. "Code Intensive" people tend to be bottom up guys - they start with code, refactor to a new design - rewrite, refactor, repeat. Call me old fashioned, but I firmly believe in the use of enterprise reference models, template architectures, application blocks, architecture & design patterns and candidate architectures. This clearly puts me in the bucket of "Big Architecture Up Front" - and I'm proud of it.
In the last 8 years at MomentumSI, I've had the chance to see hundreds of projects across our clients. And the one thing that has always amazed me is the reusability of architecture and design elements. Sure, the platforms change - new elements are added - the functional domain is different, but for the most part the basic architecture and design is usually about 80% reusable.
To clarify my position, I'm really a "Canned Architecture Up Front" kind-of-guy. In working with architects, I've noticed an interesting behavioral pattern. Application architects realize that when their architecture is "finished" they're probably going to have to do "design work" or God help them, "coding". For this reason, they tend to re-invent architectures and make them drag on for long periods of time. This is bad.
We are in interesting times. I'm predicting that the "Big Custom Architecture Each Time" guys are going to find themselves in a pinch. Microsoft (and others) are moving us into a world of "drag & drop architecture".
Microsoft's decision to embrace an Architecture Description Language (SDM - the Systems Definition Model) has the potential to overhaul the profession. SDM will likely spark a renewed interest in creating digital descriptions of our architecture, leading to an ADL competition and overall advancement of the discipline.
Digitized architecture also has a greater potential for enabling architectural refactoring, automated vendor sourcing, self-reflecting documentation and automated environment provisioning. But the thing that gets me excited is significant reduction of 'architecture time' by using enterprise-grade, off-the-shelf, canned, distributed architectures.
"The term BigDesignUpFront is commonly used to describe methods of software development where a "big" design is created before coding and testing takes place. Several ExtremeProgramming (XP) advocates have said that such "big" designs are not necessary, and that most design should occur throughout the development process."
Over the years I've noticed that the closer one is to the code, the less they tend to distinguish between architecture and design. "Code Intensive" people tend to be bottom up guys - they start with code, refactor to a new design - rewrite, refactor, repeat. Call me old fashioned, but I firmly believe in the use of enterprise reference models, template architectures, application blocks, architecture & design patterns and candidate architectures. This clearly puts me in the bucket of "Big Architecture Up Front" - and I'm proud of it.
In the last 8 years at MomentumSI, I've had the chance to see hundreds of projects across our clients. And the one thing that has always amazed me is the reusability of architecture and design elements. Sure, the platforms change - new elements are added - the functional domain is different, but for the most part the basic architecture and design is usually about 80% reusable.
To clarify my position, I'm really a "Canned Architecture Up Front" kind-of-guy. In working with architects, I've noticed an interesting behavioral pattern. Application architects realize that when their architecture is "finished" they're probably going to have to do "design work" or God help them, "coding". For this reason, they tend to re-invent architectures and make them drag on for long periods of time. This is bad.
We are in interesting times. I'm predicting that the "Big Custom Architecture Each Time" guys are going to find themselves in a pinch. Microsoft (and others) are moving us into a world of "drag & drop architecture".
Microsoft's decision to embrace an Architecture Description Language (SDM - the Systems Definition Model) has the potential to overhaul the profession. SDM will likely spark a renewed interest in creating digital descriptions of our architecture, leading to an ADL competition and overall advancement of the discipline.
Digitized architecture also has a greater potential for enabling architectural refactoring, automated vendor sourcing, self-reflecting documentation and automated environment provisioning. But the thing that gets me excited is significant reduction of 'architecture time' by using enterprise-grade, off-the-shelf, canned, distributed architectures.
Friday, April 15, 2005
SOA: Business Impact Strategy
A major shift has been occurring over the last few months in the SOA adoption curve. "Business people" are now being tasked to understand the strategic business impact of SOA/Web Services in their organization. This is a significant deviation from the last set of strategy calls around "strategic SOA implementation".
Many organizations have completed the first stage of maturity. That is, they have a SOA strategy in place, a SOA methodology, a reference model, candidate architectures and core infrastructure components (registry, repository, SOAP routers & firewalls, pipe & filter mediation, service bus, SOA EII, metadata compliance, testing suites, SOAP-to-Legacy adaptors, specialized "service servers", etc.) Typically, a core team has been trained but a larger training plan is available. Again - this is in "leading organizations" - not the majority!
These leading I.T. organizations are now giving the business units the go-forward nod, indicating that they have their act together and passing the baton to the business units to make the next move. Much like we saw in late 90's around the Web, business managers are looking at the capabilities of the technology, studying the disruptions and applying it to their domain.
I'm starting to see SOA patterns of disruption emerge - but it is still early. Very exciting - more to come...
Many organizations have completed the first stage of maturity. That is, they have a SOA strategy in place, a SOA methodology, a reference model, candidate architectures and core infrastructure components (registry, repository, SOAP routers & firewalls, pipe & filter mediation, service bus, SOA EII, metadata compliance, testing suites, SOAP-to-Legacy adaptors, specialized "service servers", etc.) Typically, a core team has been trained but a larger training plan is available. Again - this is in "leading organizations" - not the majority!
These leading I.T. organizations are now giving the business units the go-forward nod, indicating that they have their act together and passing the baton to the business units to make the next move. Much like we saw in late 90's around the Web, business managers are looking at the capabilities of the technology, studying the disruptions and applying it to their domain.
I'm starting to see SOA patterns of disruption emerge - but it is still early. Very exciting - more to come...
Subscribe to:
Posts (Atom)