I have always maintained that governance is something that SOA and BPM platforms should just have built-in. Governance should not get in the way or be bolted on, but rather be a central and cohesive part of the platform experience. I recently wrote a post for the IBM IMPACT blog that discusses why this is important and talks about the innovations we delivered in v7.5 of the IBM Business Process Manager platform to enable governance for BPM programs. You can find the post here.
Architectural decisions capture knowledge that must be shared with the development team in order to enable them to make the right design and implementation choices. Generally, architectural decisions are conscious design decisions that may concern the software system as a whole, or one or more core components. Here are the reasons I think architectural decisions should be documented, published, and actively socialized Read more »
I’ve used just about every version control system on the planet, from MS Visual Source Safe to CVS and SVN to Rational ClearCase and Rational Team Concert. I’ve even had the unfortunate opportunity to use IBM CMVC. Up until recently, I had never used the latest family of VCS’s known as Distributed VCS—namely Git and Mercurial. The Internet is filled with flame wars on which one is better, but for our purposes we decided to use Git for a project I am working on because we are anticipating a highly distributed development model with a large number of developers (50+) contributing code and we like the flexibility to customize our development, build, and test workflows in various ways. Git seems to offer the broadest range of options when it comes to workflow customization.
After reading up on how Git works from the official Git site and the Pro Git book, I found a very useful post on a successful Git branching model that describes how teams working in parallel on different parts of the code base can be successful with Git. Based on this, I decided to create centralized ‘origin’ repository to fit with our development process, andI took a stab at getting such an animal up an running on one of our development servers which happens to be running Red Hat Enterprise Linux 5 (RHEL5) . It turns out that the standard installation of RHEL5 does not include Git, however it is relatively easy to install Git 1.5 from the “Extra Package” repository hosted by the Fedora project. But Git 1.5 is two years old, how do you get a 1.7 release installed? If you are a Linux power user, you might just be asking yourself where the source code is so you can build it and that certainly is one option, however I found a much easier way that I describe here:
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
yum install git
rpm -Uvh git-1.7.1-1.el5.1.i386.rpm
perl-Git-1.7.1-1.el5.1.i386.rpm
gitweb-1.7.1-1.el5.1.i386.rpm
Each year the IBM IMPACT conference hosts hundreds of sessions on BPM and SOA from both business and IT leaders. In the past, I have been less than organized when it comes to my session agenda. This year I decided to put together an agenda which maximizes coverage of BPM related topics with a healthy mixture of technology sessions and stories from our customers and partners. If you are attending the conference this year, you can find all the sessions and build your own agenda at the IMPACT Conference SmartSite. Read more »
Production topologies can be one of the most daunting concepts to master and this book does a really good job of explaining the concepts and details. This RedBook has been updated for the v7 products in the WebSphere BPM suite and I highly recommend it for anyone who is deploying solutions using WebSphere BPM products or plans to in the future.
The RedBook can be found here.
@TimBray has a great post contrasting modern web development to how large enterprise IT shops operate. He discusses this as a huge opportunity area and I couldn’t agree more.
…Orders of magnitude wrong. Billions and billions of dollars worth of wrong. Hang-our-heads-in-shame wrong. It’s time to stop the madness.
The community of developers whose work you see on the Web, who probably don’t know what ADO or UML or JPA even stand for, deploy better systems at less cost in less time at lower risk than we see in the Enterprise.
It’s like this: The time between having an idea and its public launch is measured in days not months, weeks not years. Same for each subsequent release cycle. Teams are small. Progress is iterative. No oceans are boiled, no monster requirements documents written. And what do you get? Facebook. Google. Twitter. Ravelry. Basecamp. TripIt. GitHub. And on and on and on.
My old ritual for giving a live presentation in your typical conference setting: clip on the microphone; try not to trip over the wires on the floor; transfer my presentation to a thumb drive; load it up on the late model PC laptop on the podium; make sure the resolution looks good on the screen; make sure the recording is on; make sure my remote works; go! What a pain in the hind quarters! Practice makes perfect; you learn and adapt. I also learned what to do when things go wrong; for example, when the resolution on the screen makes your graphics unreadable by 90% of the audience and you people squinting and tilting their heads.
As the global economic downturn took it roots and blossomed into a full fledged financial meltdown, organizations began looking for ways to cut costs. The most infamous techniques involved downsizing (layoffs) and other headline making measures. At IBM, one of the casualties of the economic downturn has been “non-revenue generating” travel. The frequent visits to colleagues in different sites for the sake of meeting face to face have been going the way of the dinosaur. When a customer or partner is involved, I am convinced that there is no better company in the world than IBM at facilitating whatever the customer or partner wants – face to face meetings, etc. However, from a cost savings standpoint, it makes sense to reduce or eliminate discretionary spending, like travel, whenever possible. For the past couple of years IBM has been experimenting with virtual worlds as a way to conduct business with high fidelity interactions between people in geographically distributed locations, but without the side effects of travel expenses (including time lost while traveling). A recent example of IBM using Second Life to facilitate large scale meetings was featured in Virtual Worlds News. Irving Wladawsky-Berger also blogged about Serious Virtual World Applications where he discusses some the success stories IBM has had with virtual worlds and what it takes to make them successful.
I recently had a first hand encounter with a conference held in Second Life (SL) where nearly 200 participants gathered to hear a presentation “in world”. At IBM, we have created our own internal worlds in SL customized to host these types of gatherings. In this particular meeting, I received a link via email that teleported me away to a virtual auditorium that reminded me of a Roman coliseum. The auditorium came fully equipped with a monster sized projector screen and seats that oriented your avatar to the screen when you sat down. Next to the screen was a stylish podium where the speaker’s avatar waited to give his presentation. As the presentation began, the slides were rendered on the screen and audio was streamed through my computer’s speakers. At first, the audio was barely audible, but later a moderator sent a message to the group saying we should get closer to the avatar that was presenting! What? Perhaps this is a little too real. I am used to this kind of issue in real world presentations at conferences: there are some good seats and some not so good seats. Sometimes the presenter speaks too softly, sometimes their slides are hard to read from the back. I never expected this type of issue in a virtual world, however the creators of SL apparently think some of the real world’s physical limitations make sense in their virtual environment. This got me thinking: what can my avatar do in his virtual world that I can never do in the real world? While some of the real world physics are baked right into Second Life, its fun to think about the ones that are not and what one might do in a world where you can teleport, or fly, or create and manipulate matter like it was silly putty! While this might lead to some interesting presentations and amazing real-time collaboration (think collaborative 3D whiteboard), I also wonder if my avatar can be smarter. What if my avatar could act as an intelligent agent, listening to the presentation and grabbing interesting bits and pieces of information for me, then creating a summary and posting it as a You Tube video so I can watch it later? I could even send an army of smart avatars out to multiple presentations at the same time all with instructions to collect, analyze, and aggregate information that I find useful. Hmm…smart avatars, I wonder if this fits in the Smarter Planet strategy somewhere?
While I am still skeptical if virtual worlds will ever replace real human-to-human interactions, there is certainly something to be said about the potential for innovation within an environment where real world physical limitations are removed. Who knows, perhaps one day with practice we will all learn to adapt to the “in world” experience and attending a virtual conference will be as normal as dialing into a conference call.
This is everyone’s fault but mine.
- Homer Simpson
We recently experienced one of those product releases that make people want to jump out of the windows and hurl insults at their managers and team leads. The problems were many, but boiled down to bad assumptions and bad estimates leading to bad commitments. We also had changes in our process, tooling, and plan priorities that created a perfect storm in the development lab. A common practice on agile project teams is to hold a retrospective at the end of each iteration to identify potential ways to improve their software process. On my team, we call this ritual a “Hotwash“. The purpose of the Hotwash is to evaluate what went right, what went wrong, and capture “lessons learned” so mistakes are not repeated. While these meetings can be painful, I have found them to be one of the most valuable practices for an agile team. In our last Hotwash we decided to start capturing action items using the Retrospective work item type in Rational Team Concert. By doing so, we now have a record of what was discussed and a work item that can be assigned and put into a plan. As an example, here is one of our action items from the last Hotwash:
In this case, we learned that our daily build was running too late in Austin for our teams in India. The sentence structure of the restrospective should be in an actionable form:
Start/Stop/Continue activity so goal
For example, a team might discover that they had too many useless meetings in the last iteration of development. They would capture a retrospective like this:
Stop having meetings without a clear agenda so the development team does not waste time
Retrospectives are not always negative things. Answering the question of What went right? is equally important. These positive retrospectives can use verbs like Continue or Adopt. For example, a member of a team might have tried a new tool in the last iteration and discovered that it added value:
Adopt the new planning tool broadly so we can have transparency in our iteration plans
No matter how your team decides to capture lessons learned, the practice of looking back and learning from mistakes made and success achieved in the past will help make sure you continuously improve your team’s process and also help unify the team around common goals for improvement in the future.
A recent article on InfoQ discusses how checklists can be used to improve software quality. This amounts to a simple way to define and follow best practices on a software development team. I have used “stupid little checklists” in the past for certain things. For example, the 5 steps needed to add a new method to a public interface (including completing peer reviews, updating docs, etc.). I wonder if some of these checklists (the ones that become truly “best practices” for a team) should be enforced by the development tooling (e.g. the Jazz platform has the underpinnings to support this type of automation). We already have tools for code style checking (like CheckStyle) that when integrated with an SCM tool can reject code that fails code style rules. I have found this to be both highly frustrating (and possibly in violation of an agile tenet or two) but ultimately rewarding for the team. If every developer on my team followed some of the same checklists, how much better (and predictable) would our overall quality be? While I can see this becoming abused (i.e. draconian), it seems that a development team could benefit from the standardization and enforcement of certain best practices in the team process.