I am thrilled to announce the newest chapter of IASA right here in the Tampa/Orlando area. J. Ambrose Little and myself will be serving as local IASA chapter presidents and working tirelessly to bring interesting architecture content to a this new community.

I personally have been involved in various communities for 5+ years now. Starting with some of the early Tampa Bay developers user groups to the now thriving .NET user groups. I absolutely love spending time with other passionate professionals and with my recent interests shifting toward architecture I am finding that a new community with a different set of concerns is probably long overdue.

It is also important to realize that this community is not dedicated to fortune 500 enterprise architects. Like any other community the goal is to provide an environment where everyone can share ideas, collaborate, and learn. If you are a practicing architect, a junior architect, or an aspiring architect this community is for you.

Expect meetings to start in late March or early April. We are not ready to announce the speaker or the location at this time but trust me when I say we are working hard on it. Hopefully in the next week or two we will have something more concrete.

If you are interested at all please sign up for our mailing list at Tampa Bay IASA

A recent thread that was started on the MSDN architecture forums really got me fired up so here we go. The thread was titled "Who needs Architecture?" (see it here). The entire focus of the thread starts with a posting on whether or not small and medium projects need architecture. It then progresses into a semi-rant about why architecture matters to any company and any project.

I of course put some of my thoughts in the thread but did not want to go overboard ... that's what my blog is for:) So I really want to sound off on this topic because architecture and frameworks have been the star attraction of this thread and a recent post by Rhockford Lhotka (see it here). Both of these posts seem to be taking a strong stance against the value provided by consistency in an applicaiton architecture.

This all seems to come back to a battle to provide an easier way to build applications that meet the needs of a business user. You will see this battle being fought in conversations like the one in the first thread above. Why do I need to spend all of this time implementing some complex architectural standards when all I need to do is build 3 screens, 4 tables, and 6 stored procedures. Seems fair that for something this small you would avoid putting in all of the flexibility that a core architecture template might provide.

I would say this logic is flawed on a couple of levels. First of all there is this implicit belief that building things without using standards or guidelines takes more time. I think the real point there is that anything that you don't fully understand takes more time. If you have already implemented a core architecture template and understand the responsiblities of all the layers then you probably don't struggle as much with an implementation of that architecture. That doesn't answer the question though ... "Why should I care about this architectural template?".

You have to care about this because it is this division of responsibility and the concise implementation of the layers that makes your application much more maintainable. If you read any books on doing software development you'll see that most of the time spent on an application is in its maintenance after it has been built and delivered. So does your 3 screen application need to have a new screen created? Do you need to make modifications to existing screens to add a new data artifact. How much work is that for you? Will finding and fixing a bug take hours or days. The whole point of consistently applying a base architecture is that you should get your entire development staff comfortable with supporting and extending applications that are delivered in a similar way. The only remaining issue to is to change the perception that this is much harder to implement than the drag n drop hobbyist style application.

Now let's move on to Mr. Lhotka's post. This post attacks us from a different angle. It asks what are you doing to eliminate complexity and make building applications easier for developers? What are you doing to help your business keep up with the rapidly increasing demand for software? How is your development organization preparing itself for the new demand for software that is right around the corner (mobile devices, business process functional development, business partner integration, etc...)? Well of course I'm paraphrasing a little, this was in fact what I took away from his post.

I think Mr. Lhotka has put out a posting that is a challenge to all architects and framework developers. I continue to call all of these issues battles in our industry. well if this issue of abstracting complexity is a battle then we are losing ... losing quite badly actually. But as with any battle there are things that can help us shift the momentum back in our favor. What's that ... is it a bird? is it a plane? Nope ... it's VS 2005 and the Guidance Automation Toolkit, Domain Specific Languages, and Visual Studio Team Foundation server.

If you're an architect today you have to feel like your job is an incredibly important one. Mr. Lhotka is correct when he says that our tools are not doing what they are supposed to do. You probably can build a VB3 application faster today because of this. Why do I have to write every exception handling block, why do I have to worry about whether I use EntServ, WS, or Remoting for communicating between app domains? If you haven't already found this book "Software Factories" by Jack Greenfield you MUST buy it right now. This book starts to decompose this issue into the idea of expected complexity and accidental complexity. What we are talking about here is accidental complexity. Things that make building everything harder but we get no value from solving it. It ends up being just crap you have to do so you can hopefully spend 1/5 of your time on building out the actual business logic that the users actually do care about.

I fully anticipate that the SOA revolution and the Software Factories initiatives will change drastically how we deliver business applications. We are in an exciting time as the opportunity for innovation and leadership in this area is still desperately lacking. In the last 6 months you will have seen two important deliverables toward this end. The Domain Specific Language toolkit and the Guidance Automation Toolkit. If you are an architect and you read these blogs and say "That's exactly what I'm trying to freaking change in my company!!!" then you need to look at these things and freaking fix it ... and then blog about it because I hope to start hearing about how other folks are making this happen.

Remember the software development industry is relatively young and our last major shift was when we decided we could use Objects to represent real world things. This is likely to be the next one that drives the industry to support tools and train people to support its ultimate goal. That goal being to enable the vast majority of developers out there. The "Mort's" are often considered to have a 5/1 advantage in the business development space so tapping into that potential is the only way to cost effetively close the gap between the demand for more code and the capacity your developers have to produce.