Coding the Architecture - review tag

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.

Book Review - Understanding Enterprise SOA

Tue, 02 May 2006 15:31:40 GMT

If ever there was an overused three-letter acronym, SOA would be it. Sadly few people that use the acronym actually understand what it really means. Managers think that it is the answer to all of their problems ("Let's just get one of those SOA things in"), and developers assume that it is just exposing everything as web services willy nilly. This book aims to cut through the hype and get to the truth behind the acronym.

Initially it seems that the book is targeted towards management types, but it soon becomes apparent that there is plenty in there for the technologists amongst us. Sure, there are no implementation examples, but this means that the book is able to concentrate on the real issues behind SOA rather than the Hello World examples that so many books turn to.

The book is told as the story of the IT sprawl that is Titan Insurance. Titan face the same problem as a lot of large IT organisations in that they have a lot of disparate systems that all need to work together to be effective. The book presents the case for creating an SOA based on Web services standards to achieve the integration, and presents many compelling arguments as the why this is the right way to go. The use of a recurring example through the book helps to give good context to the explanations which is something that is missing from so many IT books at this level.

As an architect trying to sell the SOA dream, this book presents "ready-canned" arguments that you can use, and plenty of technical information to back it up. This book explores both the technical and organisational issues behind SOA and is not afraid to highlight the parts of the puzzle that are not quite ready for the prime-time yet, and preempts most of the questions that people will typically ask you about SOA.

Rarely is an IT book a compelling read, but some how this book manages to be just that. I believe that I gained something from each and every chapter in this book. I think that the primary thing that I have learnt from this book is that employing an SOA is a great way to reduce coupling between systems (be they legacy or not) and also a good way to avoid the vendor lock-in associated with other EAI techniques. I also learnt that there is a fair way to go in some areas before this is an "easy" way to go, mainly regarding security.

Conclusion

If you are a developer looking to understand the nuts and bolts of web-services, then this book is certainly not for you. If, however, you are a looking to understand the hype behind SOA and to be able to have a reasoned argument for or against it's adoption, then you should give this book a read.

Reviews

Fri, 17 Mar 2006 15:05:20 GMT

I recently read chapter 5 of Applied Software Project Management and it was all about reviews. Inspections, desk checks, walkthroughs and code reviews were all mentioned along with the compelling argument that reviews have a very high return on investment because catching a defect early is much much cheaper than catching it later. Think about it, a couple of hours spent reviewing your key use cases is much cheaper than getting somebody to rewrite and retest a software component that works but does the wrong thing.

I'll be honest, I'm as guilty as the next person in not doing enough reviews, but why do we let this happen and how can we readdress the balance? The first part of the question is easy to answer and I'd like to offer up the following suggestions.

Time : there are always better things to be doing.
Context switching : it takes a while to switch from what you're doing and focus on something else that you might not necessarily be familiar with.
Learning curve : As an architect, you're not going to know the entire system inside-out, so there's the learning curve to consider when you review something you've not seen before.
Tools : if you've installed code checking tools (e.g. PMD, Checkstyle, etc) then there's a tendency to "leave it to the tools".

So, how do we address this? Well, for code reviews, an easy answer is to adopt extreme programming's pair programming, but of course this isn't always possible and/or desirable. Something that I recommend other architects do is delegate some of the reviewing to others on the team, perhaps sitting with them for the first few reviews to help them see what you want. This is good because not only does it free you up a little, but it helps develop their skillset and spreads knowledge of the project across more of the team.

Ultimately though, you just need to make time for reviews. Ensure that they are included in any estimates and, if you're an architect, ensure that you set some time aside for reviews. As an architect you're probably responsible for the technical quality and you can't assure it if you don't review it.

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.

Service-Oriented Architecture Compass

Tue, 07 Feb 2006 10:39:29 GMT

I've just finished reading Service-Oriented Architecture Compass : Business Value, Planning and Enterprise Roadmap for JavaRanch and the review has been posed here. My summary? Here it is.

Overall, if you're an architect looking at SOA now or planning to in the future, this book will help you clarify your thoughts and steer you through the brave new world of a service oriented architecture. It comes highly recommended.

This is a great book and covers a much broader range of topics than how to build an SOA with [Java|.NET|another technology]. It'll be interesting to see how this book stacks up to the one that Sam is reviewing. If you've read this book, what did you think?