I just finished attending the 2008 No Fluff Just Stuff conference in Columbus, Ohio. It was a lot of fun, had some informative sessions and as expected these days some pointless fights over language syntax. Here are highlights from some of the sessions I attended.10 Things an Architect should know
Speaker: Richard Monson-Heafel
This session was a good eye opener for getting your head out of the sand. A one-liner summary would translate to something like: Stop wasting time arguing about implementation details and start focusing on customer needs!
Below is some paraphrasing of the top 6 noteworthy things I got out of Richard's top 10 list.
People are the Platform
People are the Platform
User interface is the most important part of your system. The point of IT is to make people more productive not to write beautiful systems. What happens underneath the hood is really not that important, as long as it works. A great UI on top of ugly middleware is much better than bad UI on top of pretty middleware.
All Solutions are Obsolete
When picking technology, pick what works best today, don’t try to predict the future.
For example a couple of years ago a lot of people banked on JSF becoming tomorrows golden standard, and are now suffering (to some extent). You can’t really predict what is going to be the popular in the future. Just pick what works best today and stop worrying about future proofing your system. There is no such thing as future proofing... it is a myth.
Data is forever, everything else can change
IT architecture keeps changing, but the data (often) lasts forever.
With that in mind Richard promoted the use of relational databases, as opposed to object databases or XML databases, which are tied to a specific technology. Likewise Richard took some shots at Rails & Grails, for probably getting things wrong in the long run. Basically stating that we should not have systems be generating our databases. We should build the database first to meet the company needs and then the systems on top of the databases. 5 years from now the database might still be there but everything else has changed.
I can agree with this to some extent, as I have had some bad experiences in the past working with tools that try to autogenerate a database based on some higher level entity. Usually what gets generated is somewhat of a mess and not easily reusable by other systems at a later time. On the flipside though, the productivity gains of newer development frameworks make them hard pass on. We just need to be mindful of taming them to some extent to generate maintainable databases.
Flexibility Breeds Complexity
Simplicity can create flexibility, but flexibility will always create complexity.
When designing a system always err towards simplicity.
Building a simple system and adding features to it later probably costs you less in the long run than building a super flexible system upfront to handle all possible future changes.
Know The Business
As a software architect you are in the tough position of having to be an expert on all things related to the technology of the company, but just as importantly you need to know and understand the business of the company you work for. You need to know the business as well as the business people! Remember, it is your job to make the business people more productive. If you don't understand what they do, then how can you help them?
Software Architects Should also be Coders
Get out of your ivory tower and into the trenches. Bits talk, Bulshit walks.
Every architect should spend at least 10% of their time doing code reviews with the engineers building their product. That’s how you see what is working well and what is giving people headache. Pull up a chair and sit next to a developer for an hour. In addition to getting a better feel for what the developer is dealing with you'll be surprised at how hard he/she will work during that hour! :)
So You Have Been Promoted to Tech Lead. What do you Do.
Speaker: Mark Johnson
This session brought up some useful points for us Tech Leads to think about.
A few of them were:
Flexibility Breeds Complexity
Simplicity can create flexibility, but flexibility will always create complexity.
When designing a system always err towards simplicity.
Building a simple system and adding features to it later probably costs you less in the long run than building a super flexible system upfront to handle all possible future changes.
Know The Business
As a software architect you are in the tough position of having to be an expert on all things related to the technology of the company, but just as importantly you need to know and understand the business of the company you work for. You need to know the business as well as the business people! Remember, it is your job to make the business people more productive. If you don't understand what they do, then how can you help them?
Software Architects Should also be Coders
Get out of your ivory tower and into the trenches. Bits talk, Bulshit walks.
Every architect should spend at least 10% of their time doing code reviews with the engineers building their product. That’s how you see what is working well and what is giving people headache. Pull up a chair and sit next to a developer for an hour. In addition to getting a better feel for what the developer is dealing with you'll be surprised at how hard he/she will work during that hour! :)
So You Have Been Promoted to Tech Lead. What do you Do.
Speaker: Mark Johnson
This session brought up some useful points for us Tech Leads to think about.
A few of them were:
- Requirements Acceptance Criteria
- 66% of requirements have no business value
- When you are on a project that gets flooded with new requirements, try to put each one of through the following pick list:
Any requirement that ends up in the "Kill" category you should bring back to the business (or product owner) and explain your case for getting that requirement dropped. On the flip side be more open to requirements that have high business value but low complexity, risk and cost. If you can get some of those in, in favor of throwing out a couple of "killers" you might make your project more likely to succeed, even though business people keep wanting to change things on you. Also, don't just automatically say no to every new request (over defend you project). Evaluate it via the above pick list and try to work out what is in the best interest of everyone involved. - Delegate
(This might have been the hardest thing for me to learn when I stared doing tech lead work) - Stop playing superman! Don't assign all the hardest tasks to yourself. You won't have time to implement them properly. Trust your developers and they will usually reward you.
- Don't go to every meeting! In most meetings nothing noteworthy happens. Delegate attending some meetings to your teammates.
- Once you come up with a plan, share it with everyone
- Make sure you have peoples buy in to what you are planning to do. If you run into trouble later people will be much more willing to help you out if you included them from the beginning.
Getting Started with BPEL
Speaker: Mark Johnson
I have to admit that this session sent a few gusts of cold shivers down my spine. I did not know much about BPEL and was kind of curious to see what the fuss was about. After doing some preaching about BPEL being XML driven and one of its design goals being "Not to define a graphical representation of processes", a few slides into the presentation Mark brought up the NetBeans BPEL IDE. To my shock I found myself staring at something that looked an awful lot like a WLI JPD (WebLogic Integaration Java Process Definition)! It tied together several web services in an elegant looking flow diagram, with forks and splits and what have you. Even some visual transformations of data from one web service passed to another. Now, for anyone not familiar with the JPD technology, it tries to do pretty much the same thing, basically tie together multiple service calls and transformations in a nice looking flow diagram. On the surface it sounds great, but my actual experience in dealing with the JPD technology has brought about multiple frustrations:
- The flow through your JPD is written in a custom XML language which ties back to autogenerated Java code that programmers are discouraged to change
- It breaks many key OO concepts such as
- No encapsulation (everything that holds data is a public global variable in the JPD class),
- No inheritance. Two JPDs for similar services are pretty much a copy-paste of eachother.
- One business method per JPD. There is only one entry point into your typical JPD.
- Some of the JPD UI language concepts don't work as expected
- For example the JPD Parallel node, which is meant to call multiple services in parallel and then wait for all to finish before proceeding onto the next node in your flow. After some hair pulling I discovered that actually doing things in sequence rather than parallel resulted in much faster code! The parallel node ends up spawning a new thread for each service call, which can be very taxing on your app server resources.
- When writing JPDs, a lot of time is spent trying to figure out how to get something working, as opposite to focusing on writing business logic.
- You never really know what is going on underneath the hood.
- WebLogic claims that you don't need to know anything about how the JPDs are implemented. But in actuality you will run into problems that require you to understand what is really going on when your JPD is being executed (like with the parallel processing nodes) . Over time you will come to realize that underneath all the glory you have a ton of autogenerated EJBs and JMS messages hard at work, but little documentation on what is really taking place.
- Most JPDs are hard to read, even for developers!
- The idea of JPD being a great tool for you to communicate your process to business people was not my experience during the couple of years I used the technology. Most of our JPDs ended up being complicated and convoluted, and we found ourselves using sequence diagrams as a more useful tool to communicate design to our business analysts. Over time we learned to simplify our JPDs, but even so I never saw them being used much when communicating with the business.
At the end of the day I decided to apply a duck typing analogy on BPEL. If it acts like a JPD and quacks like a JPD, then it must be a JPD! :-) I hope I will not have to deal with this technology in the future.
