Can architecture create a gap between developers and software they build?

The post you mentioned, Something's Fishy, questions whether we can succeed by lowering the hiring bar. But it isn't really about architecture impeding value.

I would suggest that my thoughts in IT's time to stop blaming management are much more on-topic for your questions.

Thanks for thinking of my weblog, it is always interesting to reflect on the questions InfoQ raises.

I agree with the observations made in this write up....but i feel that i has nothing to do with architecture....it has more to do with 'approach' that is taken by a company to build software systems....not with the architecture of the system being built per-se.

Thank you, Reg, for passing by and linking to your more recent post.

I agree with you that "Something’s Fishy" is not directly relevant to the main focus of this post. However, it seems to me that when you talk about “dividing up work on a project such that the people with the least experience are protected from damaging the code”, it conveys the same idea I was mentioning at that point.

Your more recent post was published after I finished my write-up. I decided not to add it because it rather speaks about the constraints architecture may put on innovation and flexibility. It is true that it oftentimes comes along with the fact that "developers tasks are taken out of functional context". Both are the result of the protectionist architecture I am talking about. But I decided to keep the focus on the gap between developers and the software they are building.

You can't compare Amazon (or Google) to any odd project. First of all, they are developing PRODUCTS, not projects.

One can make the observation that there is no customer service desk on one's project. If it would be that simple ...

The root problem is the balance of responsibility. If one outsources a software development problem and one threatens to sue the contractor's *ss if one is not happy with the result then one shifts away the responsibility from one's self and in doing so one greatly reduces the chances for success.

If one has developers in house they can indeed hang out with the girls of the customer service desk.

Is it really any more complicated than this?

If one has developers in house they can indeed hang out with the girls of the customer service desk.

Is it really any more complicated than this?

I agree with the observations made in this write up....but i feel that i has nothing to do with architecture....

Architecture based on such approach tends to simplify developers work through abstaction. If this is pushed to the extreme, developers tasks are taken out of functional context to become purely technical, which can potentially create a gap between developers and the software they are working on.

Architecture based on such approach tends to simplify developers work through abstaction. If this is pushed to the extreme, developers tasks are taken out of functional context to become purely technical, which can potentially create a gap between developers and the software they are working on.

This seems backwards. For me the point of abstraction is to encapsulate the technical and allow developers to focus on business. My goal is for every line of application code to sing about insurance.

Not than I am an agilist, but agile methodology goes a long way to deliver business value by having really good business/technical developers and tight integration into the business. The formula doesn't include weak people. I feel this is partly a reaction to the layered approach offshoring forces on projects. Offshorers may not understand the business need but they can knock out a technical spec.

With today's mature architectures, implementations like .net, java, and lamp all have well documented frameworks and best practices an architect should facilitate on projects not dictate.

Projects that are structure around layers and not use cases suck and companies that support layered projects tend to suck. Companies that focus on use cases tend to focus on business value and tend not to suck.

Projects that are structure around layers and not use cases suck and companies that support layered projects tend to suck. Companies that focus on use cases tend to focus on business value and tend not to suck.

Projects that are structure around layers and not use cases suck and companies that support layered projects tend to suck. Companies that focus on use cases tend to focus on business value and tend not to suck.

That's not very helpful advice. Layers are pretty abstract animals. They have elements of packaging, patterns and services. People attribute all kinds characteristics to layers.

It may be true (or not true) that focusing on layers has a tendency for failure. If you mean that layers should be abolished all together then this will lead to very poor code quality.

Not understanding layers may lead to rejecting them. It can also invite one to figure out what they are about and what they're designed for.

Architecture, or lack thereof, is not the problem. People are the problem - and the solution. (Andrew Clifford's comment above rings true.)

Let me propose a slight refocus of the problem:

"Functional, or Data decomposition makes it easy to drift away from the real world. Domain Driven Design and Behavioral Decomposition keeps the focus on modeling the problem space."

The problem noted in the article becomes evident when the team becomes disconnected from the problem domain. Architectures are built/grown/evolve in all cases.

The question is: do the decompositions still make sense and have a tie to the problem domain? If not, then it is a slippery slope...

Or at best focused on a very small part of the whole system. It is not only about ignoring the whole business, but partitioning results in an ignorance of the rest of the world. There are a lot of examples of such architecture.

Sorry, I guess I don't understand what architecture has to do with ignorance...
Knowing about the business is needed to create a coherent solution, but each piece needs to be nicely designed to avoid spaghettis. I guess each developer needs to keep loosely coupled with others, but they must understand what the piece they are working on, means to all the stakeholders, including clients.

Now, architectural separation of concerns and boundaries of responsibilities are not to keep in obscurity and ignorance different parts of the teams, they are to keep the structure clean and reusable. One thing are the functional elements and another one are the engineers. Furthermore, having the the least engineer attending to client chats or looking at them afterwards, will help him/her to improve the design.

So, the answer may be: No, architecture has nothing to do with gaps of that kind; policies and methodologies may dictate those non-sense restrictions, but they are not, by any means, dictated by a functional structure.

William

From my point of view, a good architecture will put the first priority in covering all aspects of functional and non functional requirements from the business need. It should simplify of all reusable components, put an abstraction level, hardly think about objects management againts the performance, using best practices of design pattern, etc.
I don't agree that would potentially create a gap if, there are good communications between architects and developers. They should have the same perspectives, commitment of quality, as well as skill development.
I believe if there is a good environment in projects communication management, there will be no gap but a good quality software.

I'm trying to imagine a good counter to this ... an architecture that requires you to know the entire system to do anything? Separation of concerns is at the heart of design. Broad business knowledge is a good thing, but it's a human problem outside the architecture.