Coding the Architecture - book tag

The role of a hands-on software architect

Wed, 10 Sep 2008 17:33:00 GMT

Becoming a software architect isn't something that simply happens overnight or with a promotion. It's a role, not a rank. It's an evolutionary process where you'll gradually gain the experience and confidence that you need to undertake the role. While the term "software developer" is fairly well understood, "software architect" isn't. This essay looks at the role I believe a good hands-on software architect should play on any software project.

Read the full essay in our book.

Mind the gap

Fri, 02 May 2008 10:58:03 GMT

Our industry has a love/hate relationship with the software architect role, with many organisations dismissing it because of their negative experiences of architects that dictate from "ivory towers" and aren't engaged with the actual task of building working software. This reputation is damaging the IT industry and inhibiting project success. Things need to change. This essay looks at the gap between software developers and software architects, offering some suggestions on how to reduce this gap and ensure projects are driven to a successful conclusion.

Read the full essay in our book.

What is architecture?

Fri, 02 May 2008 10:53:54 GMT

Architecture is a widely-used term within software development yet is very hard to define rigorously. Indeed, it changes meaning from domain to domain, company to company, project to project and even from employee to employee.

Read the full essay in our book.

Coding the Architecture : The book

Fri, 25 Apr 2008 09:32:53 GMT

We've built up a decent amount of architecture related content over the last two years and I'm pleased to announce that we're going to take this step further by extending and formalizing what we have already into a book. We're still working through the details, but our goal is to come up with a practical and pragmatic guide to software architecture. There are lots of books about the process side of software architecture, but very few about how you actually undertake the role. That's the gap that our book will be attempting to fill.

We've already put up a page about the book, detailing the sorts of topics it will cover, with the book itself being broken down into the following chapters.

What is Architecture?
About the Architect Role
Non-Functional Requirements
Technology Selection
Defining and Sharing an Architecture
Applying the Architecture
Software Architecture in the Real World

We're still thinking about the best way to publish the book, although we're leaning towards structuring the book as a series of essays (like Getting Real by 37signals) and by publishing each of the essays in a number of formats. We have a couple of essays that are nearly ready to go and we'll be looking to build up the book incrementally over the coming weeks and months. If there's anything extra that you'd like to see in the book, please let us know.

Book Review: 'Software Systems Architecture - Working with Stakeholders Using Viewpoints and Perspectives'

Sun, 18 Mar 2007 16:26:00 GMT

This is a book that I wish I'd been able to read years ago because it widens the reader's horizon to include aspects of getting a system designed and built that as a developer you take for granted. That said, it's a book that particularly resonates once you've had some experience in an architectural role and had an opportunity to make some of the mistakes identified in the especially useful 'Problems and Pitfalls' section in each chapter.

Applied Software Project Management

Mon, 22 May 2006 14:40:34 GMT

I've been reading Applied Software Project Management for the past few months and the headline is that this is an excellent book. But first some background. Why is a technical architect reading a book about project management?

My answer is simple - there's no distinct line between the responsibilities of a technical architect versus those of a project manager. Sure, there are some unique responsibilities that fall very squarely on one side of the divide or the other, but success is all about the project manager and the technical architect working together to a common goal. Both roles are about leadership and I've found that they tend to work better together if they are thinking in the same way and have a good understanding of each other. From my perspective, I read this book to better understand some of the project management techniques that I [have|haven't] seen in use and to better understand how I can help make a software project "better".

Looking at the table of contents shows you what a wide range of topics this book covers. It includes topics you'd expect to see (project planning, estimation, quality assurance, etc) and some that you might not (the benefits of refactoring, test-driven development and using Subversion). In addition to covering a wide range of very useful techniques to a good theoretical and practical depth (e.g. the Wideband Delphi estimation section was excellent), the authors also tackle lots of the other issues that you tend to encounter on any software project. Projects are all about people and there's great advice about how to deal with those tricky situations, such as what to do when your boss tries to cut the estimates. I really like the way that this book tackles the more human aspects of the role and it has a great section about how leadership is about responsibility, authority and accountability. Much of this is equally relevant to the role of a technical architect.

My only niggles with the book are (a) it's pretty much solid text for 300 pages and (b) towards the start of the book some of the techniques feel more applicable to waterfall style lifecycles, although the latter chapters seem to embrace iterative development more. These are minor though.

In summary, this book is 300 pages of solid advice and, at the end of every section, leaves you thinking what you'd read was just common sense. This is a very powerful feeling that I found motivated me to want to put some of it into practice. Of course, if it was all common sense then we'd all have perfect projects. But we don't. If you want to learn more about project management techniques and you want to help make your projects better, this book comes very highly recommended.

Mastering the Requirements Process

Tue, 25 Apr 2006 20:19:20 GMT

I've just received a copy of Addison-Wesley's "Mastering the Requirements Process" 2nd Edition to review over the next few weeks. The blurb says:

Mastering the Requirements Process, Second Edition, sets out an industry-proven process for gathering and verifying requirements with an eye toward today's agile development environments. In this total update of the bestselling guide, the authors show how to discover precisely what the customer wants and needs while doing the minimum requirements work according to the project's level of agility.

I'll be reading it over the next couple of weeks and posting a review after that. Please feel free to post any specific questions and I'll try to answer them in the review.

Book Review - 'POJOs in Action'

Thu, 09 Mar 2006 12:22:57 GMT

Chris Richardson's book is a well-written and thorough guide to implementing familiar Enterprise Architecture patterns with POJOs. Aimed at the designer, the book provides valuable advice on the benefits and potential pitfalls of using Spring, Hibernate, JDO and iBATIS to implement scalable, performant systems. Highly recommended.

Understanding Enterprise SOA

Wed, 08 Mar 2006 21:32:03 GMT

The Register have just published a review of Manning's Understanding Enterprise SOA. Their verdict?

For developers looking to get to grips with the nuts and bolts of SOAP, REST and the, er, rest, this isn't the place to look for details. This is decidedly not a book for those about to cut code. However, if you want to make sense of all of the SOA fuss and how it fits in with the web services you're crafting then this is definitely a good place to start.

I wonder what Sam will think of it.

POJOs in Action

Tue, 14 Feb 2006 12:40:03 GMT

I have just received a copy of Manning's 'POJOs in Action - Developing Enterprise Applications with Lightweight Frameworks' to review over the next couple of weeks. The blurb says:

There is agreement in the Java community that EJBs often introduce more problems than they solve. Now there is a major trend toward lightweight technologies such as Hibernate, Spring, JDO, iBATIS, and others, all of which allow the developer to work directly with the simpler Plain Old Java Objects, or POJOs. Bowing to the new consensus, EJB 3 now also works with POJOs.
POJOs in Action describes these new, simpler, and faster ways to develop enterprise Java applications. It shows you how to go about making key design decisions, including how to organize and encapsulate the domain logic, access the database, manage transactions, and handle database concurrency.
Written for developers and designers, this is a new-generation Java applications guide. It helps you build lightweight applications that are easier to build, test, and maintain. The book is uniquely practical with design alternatives illustrated through numerous code examples.

I'll publish a full review in a couple of weeks. If you have any specific questions about the book, please post a comment and I'll try to answer them in the review.