Quote
Sounds good Danny, I wish you and Borland all the best with this
endeavour.
Just two notes to this:
1. "SPI" and many other TLA's have come before SDO and have
been equally stubbornly barfed out by resilient and untameable software
development teams, who see this sort of initiatives as something
that threatens their "way of life".
What will Borland do to make sure SDO becomes more than
just another quickly-buried acronym?
First of all, this won't work if we, Borland, don't use these new tools
ourselves. We're our own "guinea pigs." The whole idea behind this is that
the development teams *already* have a process. What we are doing with SDO
is to take the "artifacts" that are generated from the normal functioning of
this "process," and now add higher level tools to so that the entire
development food chain can see how things are going. The idea is that the
developers and dev managers, QA and QA managers all continue to work and
interact as they always had. This is assuming that these team already use
*some* kind of defect and source tracking tools (you *do* use these tools
don't you ;-). However, huge amounts of data are generated as a result of
the whole ALM (Application Lifecycle Management) process. Using a
requirements management tools is also a very key bit of tech that
development teams should embrace. It is that end of the product spectrum
through which change requests can come in and risk/impact analysis can take
place.
The upper VP's of application development don't care about what lines of
code changes and what was checked into the archives, nor are they worried
about what set of defects got fixed. What they want to do is be able to see
at a glance what the impact a change request will have on the project. They
want to see if there is a reasonable "glide-path" to project completion that
will result in a successful delivery and on time.
The IT-Ops guys want to know what hardware configurations they are going to
need to get setup and ready for this new deployment rollout. They need to
be able to also see the status of the project and remain a key part of the
whole development process. Making sure hardware is in place at the right
time without undue delays in the acquisition of the hardware, or making sure
that the hardware isn't inplace too soon and is an unnessesary expenditure.
It's about the whole process. ALM continues to be the core to this whole
strategy. Dev tools are core. Developers are core. As Boz presented in
his session, unless we can help the whole process succeed, it doesn't matter
how much of a hot-shot you are. If any part of the whole software process
(business needs, software creation, and deployment) fails, then everyone has
failed.
Quote
2. I assume all this doesn't mean that you are conceding the low level
dev tools (compiler, IDE, frameworks) game to Microsoft?
Absolutely not. The IDEs and the actual dev tools are core to this whole
strategy. By building/partnering/acquiring other technologies, we'll be
able to also address the needs of the *other* roles in the whole chain.
--
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corporation.
blogs.borland.com/abauer
