Establishing a Class of Databases

A lot of people ask me about the infrastructure required to establish a class of databases.  In my opinion, that's not a lot of the work.  It takes a day or so here or there to write just what you need, just when you need it.

Nevertheless, I would like to remind everyone that the sample code for my book also contains sample infrastructure.  Feel free to take that as a starting point and go forward.  If you're not a .NET person, it could pretty easily be translated into Java.

Reminder: VSOA on DZone

I know it's lame but I don't care.  If you liked my article on value-stream-oriented architecture, please remember to go vote for it on DZone.  If you didn't like it... I don't know... go to hell or something?

Value-Stream-Oriented Architecutre

Like I said, previously, I'm writing a series of articles on the subject of architecture.  InformIT just published one of them, entitled How Value-Stream-Oriented Architecture Can Help You Create Better Software.  That's the first step, and it was the thing that convinced me that you can do architectural-style work in a value-driven way.

A friend of mine and I will be publishing another article on the subject of TDD at the architectural level of design in the fairly near future.  So, if you like the Value-Stream-Oriented Architecture article, stay tuned for the Test-Driven Architecture article that follows.

Test-Driven Database Development Talk at the Portland Chapter of DAMA

Recently, I gave a talk on the subject of test-driven database development at the Portland chapter of the organization known as DAMA (DAta MAnagement).

I was surprised by a couple things during this talk.  For one thing, the group was a lot more engaged than I've ever seen at this kind of talk.  For another, I expected the audience to resist the ideas a lot more than they did.  Finally, I expected to encounter new classes of objections that I had not previously addressed but none were raised.

A Great Group

It's not often that I get to (read: "choose to") say positive things about an entire group of people but this is one of those times.  The group was attentive.  They were very focused on what I was saying.  That's not a back door complement for myself either.  I've delivered virtually the same talk to other crowds and seen a lot more droopy eyes.  This is just a voracious group that wants to hear someone's ideas.

That level of attention to detail, naturally, gave rise to an unprecedented level of engagement and involvement.  The questions were piercing and pointed.  They demanded good answers.  They gave many opportunities to elaborate.  Yet, there wasn't "that guy."

Everybody who's been involved in public speaking knows that guy.  There's almost always on in every crowd.  The person who objects for the wrong reasons.  Sometimes it's because they like the sound of their own voice.  Sometimes, because they want others to hear how smart they think they are.  On occasion, they object for objection's sake, subscribing to the same basic motives as a vandal.

This group, at least when I talked to them, didn't have that guy and it made the speaking process so much more enjoyable.  Not only were there a lot of good questions, but there were only good questions.  Not only was it a lot of engagement, but it was all thoughtful engagement.

Little Resistance

I was a little nervous because I have traditionally engaged programmers who are affected by database development processes and this was an entirely different audience: mostly people who's primary skill was database development, administration, or support.  In many cases, especially in large organizations with so-called "centers of excellence" (read: "centers of delay"), application developers and data managers are at odds with one another.  At least, the application developers with whom I converse present things that way.

This talk served as evidence that things are that simple.  The group was very open to new ideas and to enhanced collaboration.  In fact, some of their questions seemed to imply that they were concerned with how to get application developers to adopt these concepts.

I now suspect that, in many organizations, data manager types and application developer types each see the other group as stubborn and distant almost entirely on account of the inefficiency introduced by the management structure in which they work.  That is, the people are reasonable and are willing to work together but their organizations impede collaboration by concentrating into skills-based groups rather than product-based groups.  This invalidates some of what I wrote in a previous entry entitled "Breaking Down Barriers to Agile Database Development" but maybe not all of it.

The resistance I did meet was mostly good, coming in the form of tough questions posed by people with real obstacles to overcome.

Bases Covered

Apparently, I'm getting good at this or something.  There wasn't a single question asked that couldn't be answered either by something from my book or by basic TDD/Agile wisdom.  This was surprising.  I really thought that, given the new type of audience, I would be facing some new tough questions.

In reality, something like a third of the questions were directly addressed by the content I brought with me.  That was really gratifying because a lot of the time I got to say "That's covered in a future slide...<click>...this one!"

Another third was covered by chapters in Test-Driven Database Development: Unlocking Agility.  There's not a lot you can do about that.  You're allotted a certain amount of time.  If you have more material than that block will support, you either cut scope or depth.  This talk was already a surface-view of the problem and solution, so cutting depth wasn't an option.  Besides, there's nothing wrong with having concepts that entice people to buy my book, right?

The last third was just basic agility or TDD questions.  I could have covered more agility and TDD concepts at the beginning of the talk but that would have forced me to cut even more scope at the end.

Regardless, the questions that were asked were easily addressed.  That's not to say I convinced everyone of everything - especially people who were at the beginning of their journey to agility.  However, the fact that there was an answer to every question made me happy.

Conclusion

It was an enjoyable and rewarding talk.

If you've got a talk that you thin might apply to this group, I highly recommend them.  I know I'm not the only one, either, because their speaking calendar is filled something like a half year in advance.

Blogger Feature Request

I really wish there was a setting I could find that got rid of the "Publish" button and forced me to mark something published from my posts view.  First of all, I keep accidentally hitting "Publish" when I mean "Save."  That's my fault but it still sucks.  Secondly, it annoys me that the words "Publish" and "Schedule" are not always applied correctly and that seems easier to get right when you're looking at a list of saved entries.

Not that big a deal but it might be worth doing.

Architecture Articles

Sometimes with a partner and sometimes on my own, I've started developing a series of articles on the topic of architecture.  It's a topic that I resisted for a long time and am finally coming to terms with in the year 2013.

Vive la Résistance

When I first got into agility, something like eight years prior to the date of this post, I grew instantly allergic to the role of "architect" and, therefore, to the concept of architecture.  "Designs can and should be grown," I would say, "so why would we want a person or activity that prescribes design in advance."

I was able to hold and defend this kind of opinion for years.  Partly, that was because architects in the day were like politicians - the ones who sought the position were those least fit to hold it.  Partly, that was because I worked on teams so small that the need for an architect was either non-existent or non-apparent.

Then something happened.  People I knew - reasonable people with good minds and intentions - started becoming architects.  To my surprise, the people I knew and respected started accepting the role of architect and the design artifacts of architecture.  Even more surprising: they stayed reasonable and worthy of respect.

That wasn't enough to convince me, though, because one of my mentors had spent years drilling into my head that exceptional people can deliver value even under the most adverse conditions.  So I was shocked to find out that value could be delivered by these people and that they were not corrupted by the station, but not enough to revisit the negative connotation I hung on the word "architect."

I started thinking back to before I was an agile evangelist and lean thinker.  "When I was just starting out, some of the most important and supportive people in my career were architects," I told myself.  The confirmation bias is strong in this one, though, so I said "They were just more exceptional people and it just looked like they were successful because we didn't understand agility."

My Last Stand

I'm known for my stubbornness, so it should come as no surprise that I resisted the need for architecture and architects in general up to the point where I was made one and beyond.  It's all a blur, now, but for at least a year I was labeled an architect and did everything in my power to not be one.

None of this is really particularly out of character but, in the course of that year, I refused to acknowledge architecture meetings, sabotaged myself, and blocked other architects from accessing the team.  In effect, I used my position as an architect to become a sort of architecture antibody.

Finally, I was backed into a corner.  I had to play the role of the traditional architect - envisioning a solution far greater than we could hope to achieve in the near future.

I mean.  I suppose I didn't absolutely, positively have to do that.  I could have gone and found a new job but I've been having a lot of success where I am and I didn't want to abandon the organization so I bent.  Just a little, but I bent.

Surprise!

That's what convinced me.  Bending just a little produced a valuable outcome.  I saw for my self, with my own two eyes that architectural work can be done without sacrificing lean or agile principles.

If you blend the goal of architecture (big picture, vision-level design) with the principles of lean thinking and agile software development you can produce artifacts that are lightweight, high-value conversation pieces.  The architectural documents you create are interesting at the executive level as well as at the individual-contributor level.  Most importantly, these artifacts help the team by documenting ideas rather than harm them by creating commitments.

That's what the articles I'm writing are about: fulfilling the goals of architecture-level work without undoing any of the progress we've all made toward emergent designs and agile process frameworks.