Coding the Architecture - sdalton

Question of the week

Fri, 04 Apr 2008 09:39:11 GMT

As mentioned last week, we are going to be sharing questions that we get asked that seem applicable to the CTA audience. Feel free to e-mail us your questions or use the Google Group.

This weeks question is from a new hands-on technical architect.

Let me ask you, what are some good resources for hands-on technical architects?

A very good question, and one with a multitude of answers - we certainly don't have a definitive list of resources, but can certainly tell you some that we find useful.

Web

The Coding the Architecture Website
InfoQ

InfoQ Architecture Community

Technorati

this one

Books

Software Systems Architecture - Working with Stakeholders Using Viewpoints and Perspectives by Nick Rozanski and Eoin Woods

book

here

Beyond Software Architecture

book

Podcasts

The Coding the Architecture Podcast
Software Engineering Radio
The Java Posse

Real Life

Local architecture or technology special interest groups

CTA Usergroup

It is worth remember that to be a sucessful hands-on architect, you also need to keep track of the underlying technologies, not just architecture. Another point to note is that it's not just about having resources specific to architecture but about digesting the resources that you use at the appropriate level.

If you have any more resources that you have found very useful then feel free to leave a comment.

Podcast #2 : QCon revisited

Tue, 25 Mar 2008 10:23:20 GMT

As promised the 2nd CTA podcast is a roundtable discussion between some of the CTA contributors - namely Simon Brown, Sam Dalton and Kevin Seal. In this podcast we discuss some of the themes emerging from the recent QCon conference held in London and our views on those themes.

The podcast can be downloaded here or you can subscribe. Full show notes follow below:

1. Introduction

QCon Conference London detail can be found here.

2. Monitoring and Management (0:27)

Roll your own vs. "off the shelf" monitoring
Asynchronous monitoring
JXInsight
The need for an System Architect and an overall understanding of WHAT to monitor and a holistic view
Including Monitoring NFRs upfront in SAD
Monitoring the monitoring vs. best effort
eBay and 1.5TB of monitoring and logfile information per day

3. Rehashing Refactoring (11:56)

Refactoring now mainstream, now emphasizing at the micro-level
Code-debt - how can you measure it?
Refactoring is not something to be "saved up"
Lots of rearchitecture projects sold as refactoring
Sometimes starting again is a better solution than large scale refactoring
Why do things end up in such a mess so often?
Need to get back to writing code for humans to understand
Worry about emphasis on low-level code optimizations rather than architecture
Is refactoring its own worst enemy being referred to as a separate discipline to regular software development?
We are our own worst enemies - we (especially the architects) need to stand up for the quality of our code - stop allowing ourselves to be convinced to make shortcuts

4. The Return of the Architect? (25:08)

Thinking about performance, monitoring etc upfront
Terracotta, Coherence, Gigaspaces
Kevin's views on Terracotta
How much performance could you squeeze from a system in 2 weeks with code changes alone?
Real-time VMs and performance improvements
The benefits of continuous performance testing
Premature optimization
Understanding a system's deficiencies can be as valuable as fixing them

Has Agile become a dirty word?

Tue, 11 Mar 2008 15:50:10 GMT

A few years ago, Agile was everywhere. There were books galore, articles in the technology press, tracks at conferences etc.

That is not to say that it has gone away, but a few years ago everything was being sold and hyped as being Agile. Things from process to products to services were having the Agile name splashed across them - whether it was a correct use of the term or not.

In some ways this was a good thing for the Agile movement as it got the term out there, and a whole lot of people were exposed to it. Some of the more curious people may even have done a bit of research and truly understood the tenets of Agile as a result. However, I would argue that this has had possibly the biggest detrimental affect on Agile possible.

We are now in a position where we have managers that feel that they were bitten by Agile when in fact what they were bitten by was miss-selling. Consultancies sold Agile and did Cowboy.

This has resulted in an allergy to all things Agile amongst many senior managers and budget holders - to the point where even mentioning the word results in a death stare. This is also resulting in a shift back to the perceived comfort of tightly controlled processes that give the managers and budget holders an illusion of control. They fail to realise that actually what they have is a stifling of productivity and ingenuity, and a company of frustrated people who can see there is another way.

My question to you is simple - have you experienced this and how have you approached it?

The First CTA Podcast

Thu, 06 Mar 2008 12:05:29 GMT

As mentioned at the last user group, the members of the Coding the Architecture website have decided to start producing some podcasts.

This was born out of a request to make the user group sessions available to people that could not attend the actual session. As such the first podcast is a recording of the user group that took place on 4th March in London.

You can download the podcast here, and if you have iTunes you can download the enhanced podcast - including all of the presentation slides - here. You can subscribe to all of our podcasts using this feed, and we will considering adding this to the iTunes Podcast Directory in the future once we have a few episodes recorded.

Look out for more podcasts from us in the very near future. In the meantime please let us know what you think, and if you have any suggestions for future podcasts.

Architecture as a Separate Function

Mon, 03 Mar 2008 15:04:00 GMT

Back in 2006 we wrote about how Architects are Part of the Team and shouldn't sit in ivory towers. This entry addresses some of the problems that arise when this is not the case.

In several organisations that I have been exposed to the architects sit within a completely different organisational area to the development team. Whilst I can appreciate this from a budgetary and reporting perspective (to an extent), it causes a number of very visible problems.

Architecture - the missing link between sales and delivery?

Wed, 17 Jan 2007 17:34:44 GMT

Having worked in a number of consultancy organisations I have plenty of experience of projects (or people) being mis-sold by sale teams and the delivery side of the organisation having to pick up the pieces. Often this is in the form of working people into the ground to deliver on a misguided promise, and sometimes it is in the form of having to replace good people when they get disillusioned.

Quite often this situation arises through the desire of a sales team to "meet targets" irrespective of whether an opportunity is strategic or in fact achievable.

It is clear to me that this is behaviour that needs to be controlled in someway in order to prevent organisations from churning through people and having to continually employ to stay at the same size, and from lacking any sort of technical direction.

Often there is a process of career guidance in place in an organisation that is supposed to help ensure that people get the right opportunities to develop their career in line with their aspirations. Whilst being a noble cause, this often fails to achieve its goals as the guides have no say in the opportunities available.

So how do we ensure that the sales team is selling things that are in line with the aspirations of the staff, the technical direction of the company, and that are deliverable?

It is quite common for organisations to carry out in-depth bid reviews before a bid is actually submitted to a client, but to my mind this is too late. There needs to be continuous, upfront technical involvement in the sales process. This could involve an individual architect taking responsibility for the technical direction of an account, or a group of architects taking responsibility for all accounts. This group of people would also help to enforce the technical direction of the company, and can facilitate technical knowledge sharing across accounts to enable work to be more effective. All opportunities would be passed through this person (or group of people) before a commitment to bid for/take on work is made. They would have the power to veto any individual piece of work, so long as they can provide adequate justification for doing so.

There are several significant barriers in most organisations to the adoption of an approach such as this. Chargeability is perhaps the most significant barrier - there is such pressure to keep people utilised 100% of their time on paying work that this sort of thing is rarely sponsored at the right level. This lack of sponsorship leads to the issue of empowerment. People need to be given a lot of power/influence in order to be able to effectively do this role - it is far too easy for the sales team to ride roughshod over technical people, or simply ignore them entirely. I have had first hand knowledge of this on several occasions.

Is anyone out there lucky enough to be involved in the sales process in this way? If so I would love to hear how it works in practice, and whether it has made a difference to the organisation as a whole. Or is there a more fundamental question here with regards to the effective size of a consultancy organisation, although that subject is perhaps dealt with in another post.

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.

Understanding Enterprise SOA

Mon, 06 Feb 2006 11:15:43 GMT

I am currently reading Manning's Understanding Enterprise SOA. This book aims to give technologists and business people an intergrated picture of the issues and their interdependencies using a continuing case study. I hope to get a "beyond the hype" view of SOA and to understand better the business concerns behind SOA.

I will give a full review when I have finished reading the book, and I have high hopes from what I have read so far!