Thursday, April 29, 2010

Being an “Agile” Signatory

Recently, I posted a Status Update on LinkedIn announcing that I had become an “Agile” Signatory.
Those of you who follow me on LinkedIn or Twitter will know that being an “Agile” Signatory aligns with my overall attitude toward information technology. You may recall some recent posts: “
Enterprise architecture is at the nexus of business and technology”; “IT Architects are business professionals who apply architectural skills; just as other business professionals apply their skills”; and, “Architectural Organic Unity: containing all required & nothing unnecessary, all relationships & integrations being essential & inevitable.
I received an excellent reply from Steve Braver, “This would appear to conflict with your previous update on PM Best Practices, unless your position is that SDLC and Agile can both be valid approaches depending on the nature of the organization and project. That's what I believe.” __ Steve Braver, LinkedIn reply, 2010-APR-29
His thoughtful reply is the inspiration for this posting.
Actually, there is no conflict at all. Project Management methods and Solution Development Lifecycle (SDLC) methods are just that -- methods. Agile is, among other things, an approach to how to best tailor and apply a method – it is a mind-frame.
As I've read "The Enterprise Unified Process: Extending the Rational Unified Process" and "A Practical Guide to Enterprise Architecture", I've come to realize that I applied an Agile approach even when I worked with DoD standards. Many people think that DoD standards imply a boxcar load of documentation and process. However, that is not true. I was taught to tailor the DoD standards to just what was needed for the project. I've always taken a business-oriented suitably-tailored approach regardless of the method at hand: DoD, NASA, FIPS, Hoskyns, Method-1, GS-Method, and RUP.
RUP, which is extended to the EUP and AUP, can be performed "Agile" or not. In fact, I recently (a few years back) worked with a client that over-engineered RUP with process and documentation. It became quite unwieldy as well as entirely unnecessary. I observed that the tendency to over-engineer process and documentation was linked to a profound lack of understanding of a subject -- in this case, RUP.
I’ll continue to read these two books until I complete them. I am sure I’ll learn much more, However, at this point from reading and experience, I see no conflict between having methods and being Agile.
__ Joseph Starwood (www.linkedin.com/in/JosephStarwood)

Monday, April 26, 2010

Rattlesnakes Sunning

Spring’s warming sun is here. Warming in the sun is the inspiration for this posting.
I began my professional life as a Minerals Exploration Geologist & Geophysicist. I prospected for copper, molybdenum, silver, and gold from central Texas to northern California.
One brief project in Southeastern Arizona was led by a Geologist who had recently received his Masters degree. With the exception of academic field work, this new Geologist had never lived and worked in the wilderness.
On our first full day at the prospect location, we took geochemical samples together from early morning through mid-afternoon. Our work plan began at our base camp, extended out in a loop covering several abandoned mine sites, and returned to our starting point.
Sampling a very large mine site at far end of the prospect area required more work and time than planned. As we worked, I noticed the sun getting lower in the sky, and shadows extending on the east-facing hillsides.
Rattlesnakes would soon move onto the rocks in those growing shadows to warm themselves. Hiking back to our base camp would be very dangerous once the sun was behind the hillcrest.
I advised my colleague about the danger, and the need to work our way back to the base camp. We had sampled only half of the mine site, and he wanted to complete the work.
After further urging, he finally agreed to leave this mine site; provided that we take some quick samples at the remaining mine sites on the way back. As we peered into the next mine site, a horizontal tunnel into the rock face, we spotted a large rattlesnake moving toward the entrance.
This new Geologist asked, “Is that what I think it is?” I replied, “Yes. It’s a big one; the second biggest I’ve seen yet. It’s moving to the warm rocks.” Seeing this, he decided to return immediately to our base camp. We completed our geochemical sampling the next day.
So what does this have to do with information technology? Much! Experienced professionals know many things that less experienced professionals do not, as well as many things that are not taught in school or written in books.
Tom Bilcze, my colleague in our IT Department, shared this reply in response to one of my postings:
“I think a general perception in IT is that architecture immediately implies complexity and more cost. … I guess the success of architectural simplicity is to actually see it being used as a natural work process and not being deemed as an overhead and unnecessary evil.”
__ Tom Bilcze, 2010-APR-20, Reply to Status Update on LinkedIn
Enterprise Architects and IT Architects face constant challenges from other IT professionals regarding architecture’s apparent complexity and cost as well as its purpose and value. Unfortunately, these IT professionals are not experienced in Enterprise Architecture and IT Architecture.
These IT professionals most often encounter Enterprise Architecture and IT Architecture through the Target Architectures (a.k.a. Project Start Architectures) provisioned to their projects. Because the Target Architectures address requirements and constraints in the context of the broader Enterprise Architecture, it appears to the project team as being more complex and costly as compared to developing the project in a silo.
However, businesses can no longer afford to develop IT solutions in silos. Business agility depends upon flexible and resilient IT components including services, applications, and COTS packages as well as their integration.
A well-crafted Target Architecture meets the requirements and constraints allocated to the project, and it conforms to the assigned milestone in the Enterprise Architecture Roadmap. It possesses “Architectural Organic Unity” (See: Prior posting).
Such a Target Architecture provides the flexibility required to realize business agility, advances the Enterprise Architecture according to the Roadmap, and establishes the foundation for IT project success.
__ Joseph Starwood (www.linkedin.com/in/JosephStarwood)