Stop Hiding Behind Your Role and Get it Done

Discussions

News: Stop Hiding Behind Your Role and Get it Done

  1. Stop Hiding Behind Your Role and Get it Done (18 messages)

    I've noticed some changes taking place in the culture of the Information Technology industry and to be blunt, they ain't great. It seems as IT organizations mature there is more and more segregation of roles on IT projects; and although the intention is good (and arguably, necessary) in many cases, it's not working. The good news is, I have an idea on how we can fix it. Let me explain what I mean by starting with an example from the past. About 30 years ago the main platform for application development was the mainframe. The structure of the teams that built these systems was relatively straightforward. There were business folks (accounting, hr, marketing, etc.) that had specific business problems, or requirements, and there were developers that built systems to solve them. The developers worked directly with the business on their issues, and were thus forced to understand the needs of the business in order to solve their problem. On the flipside, the developers also understood all aspects of the mainframe: the data structures, the code that needed to be written to process them and the constraints of the infrastructure on where code could be deployed. In other words, they knew it all, soup-to-nuts. They were clear on the business drivers , they were clear on the design and implementation work that needed to be done and most of all, (and this is where I'm going with all this) they were accountable. With the advent of distributed systems and larger, more complex, customer-facing applications, this model became unmanageable. Technologies matured and segregated and developers started aligning themselves with specific skills, often delineated by various parts of the system (the network, the database, the infrastructure, the application server, the web content, etc.) In order to manage these complex projects, Project Management took hold to coordinate all of the tasks that were needed to build a system, and Architects emerged as the glue to hold all the technologies together. Since these guys were so busy, Business Analysts came about to act as a liaison between the business folks and the technology teams. This is all well and good, but something important has gotten lost in the process (in many cases) 1. Understanding of the business needs and drivers 2. Understanding of the business system as a whole and behind door number 3 . . . Accountability Read the rest at http://jjschwan.blogspot.com/2008/07/stop-hiding-behind-your-role-and-get-it.html

    Threaded Messages (18)

  2. In my experience any organization that has titles such as "Solutions Architect" tend to be the sort of dysfunctional environment where people do hide behind their roles. "Architects" do "strategy" and "big picture", "designers" do UML diagrams, developers should implement said UML diagrams and shut up. If something goes wrong it is ultimately the developers who didn't understand the design, or the designers who didn't understand the architecture and so on and so forth. Ring any bells for someone? It's a brilliant ponzi-scheme organization chart where higher pay grade and perceived value goes with less and less actual accountability.
  3. I agree[ Go to top ]

    +1
  4. If something goes wrong it is ultimately the developers who didn't understand the design, or the designers who didn't understand the architecture and so on and so forth. Ring any bells for someone?
    All St. Peter's Cathedral ones :-) Anyway, what you say it is true in my experience since a very long time. What I see is often missing is a technical (very very skilled) responsible that is able to keep business specialists and developers together.You know the devil is in the details and Solution Architects and any other similar silly roles have no time (well, read will here) to put their hands in the real development process. Once I knew a guy that after 1 (one!!!) year working as a developer said it was tired to do its job and it was time change role and coordinate people. I would not be surprised if it is a Solution Architect now. Guido
  5. Seems to me this is only natural. I does not mean you will fix it, but you must try to get it done. You have atleast 2 roles in a project. One the practical role (ie Architect, designer etc) and 2 the role in which you must do all you can to ensure the succes of your project. The latter one is most difficult to do for many people :) kind regards, Marc
  6. It does not have to be that way[ Go to top ]

    In the department I work at, I recently moved into the role of a solutions architect. However, the way the role is set up, we are really expected to deliver. 1. First, we are expected to know the nuts and bolts of the software tools that are covered in the proposed architecture, and not just at a high/conceptual level. 2. Provide working prototypes to prove any new patterns or techniques being introduced, particularly if new technology/products are being introduced. These will then be used by the development team to get up to speed. 3. Defend the architecture that is proposed in peer reviews on the soundness of the software solution, as well as how well it fits in the current environment, and whether why any other potential alternatives were not considered. 4. Developers have an open line to you if they need help with low level design or development activities. Again, this is particularly important when you are introducing new solution patterns, or new tools/technologies. All of this means that we need to know the current environment well enough, understand the business requirements, and also have a good grasp on the tools that we will propose using in the target solution. After being in this role for a few months, I have a new found respect for the architects I interacted with when I was a part of the development team.
  7. A good article and quite right IMO. Here are a few additional points about teams formally structured around layers/modules: 1. Evolution becomes bogged down in zero-sum games. If I need a change in your module to improve my module it boils down to me getting the pay off and you paying the cost. This might only be resolved by a boss and a meeting, sometimes multiple instances thereof. 2. YAGNI (You Aren't Going To Need It) is hard to adhere to if you are "boxed" in to a single layer or module of a system because by definition you are in no position to make accurate judgments about other modules/layers real requirements. So you try to second guess every imaginable use you module's "customers" might have and risk over-engineering your API (or just getting it wrong). More documentation to explain it as well, and more meetings defending it. 3. If someone is given sole responsibility for a particular module or layer, they might think it would pay them personally to defend their "territory" in order to enhance their job security. They might even deliberately obfuscate/mystify what they are doing in order to be seen as "indispensable" by management with an eye on their next salary review. They might also try to implement some functionality using "their" technology stack that in reality would be better done elsewhere, in order to expand their "empire". 4. Teams structured like this need managers (whatever they are actually called) to resolve these problems, and the managers necessarily get paid more than the programmers. Most of these problems are "people" based, not technical issues, so the key qualifications for promotion are people management and conflict resolution, not technical knowledge and ability. Queue rerun of your spoof meeting from your article. Open source projects have their own set of problems, but they do not on the whole suffer from these ones. Management is (mostly) replaced by a defined development process and a set of house rules for submitting patches. Development is use case driven (feature led development) and control is maintained because each patch must pass muster on a) integration with the test/build suite, and b) peer review. Booch and Jacobsen advocated a use case driven approach over a decade ago and there is no reason why a commercial shop cannot work like this. Google do, at least they do in the GWT team to my certain knowledge.
  8. In large organsations the architects always keeps the helicopter view and do not wish to see the low level details. It's upto the designers to communicate between the architects and developers to keep them in sync. Also I have seen that when a developer does not know the background or the architectural reasons the quality of the delivery just goes down. In small organisations the architect & designer roles are carried by the same person where by they have the responsibility to understand the complete details.
  9. In large organsations the architects always keeps the helicopter view and do not wish to see the low level details. It's upto the designers to communicate between the architects and developers to keep them in sync. Also I have seen that when a developer does not know the background or the architectural reasons the quality of the delivery just goes down. In small organisations the architect & designer roles are carried by the same person where by they have the responsibility to understand the complete details.
    I think an architect who does not wish to see the low level details represents a good cost cutting opportunity.
  10. I think an architect who does not wish to see the low level details represents a good cost cutting opportunity.
    Yep! During good times, companies are flushed with cash and the only problem is how to justify giving higher salaries and bigger bonuses. So they inflated the titles and created big bureaucracies in the IT department. The result is a whole new class of dead-weight bureaucrats with titles like "solution architects" who do nothing and are responsible for nothing. Now that business is tight and money is hard to come by, only those companies that lose the "fat" will survive.
  11. I won't pretend to have all the answers, but over the years I've become convinced that trying to push everyone into fine-grained roles that they do all the time is just...BAD. Worse than bad :) The more useful approach I think is to have very smart people who do different functions at different *phases* of a project. In an ideal world the uber-smart developers would talk to the business with their manager there to keep it civilized, etc. Then the same guys would throw around ideas, and start whiteboarding the architecture. Pretty soon they'd be done and have agreement on the plan. Then the same guys would start coding. Creating contrived distinctions between "solution architects", "technical architects", "developers" and so on is just too daft to even think about.
  12. Good article. It's become a trend these days to have larger teams, many roles and needlessly complicated architectures. It hurts most when architects hide behind because technology makes up the most part of an IT project. And these bad architects generally tend to introduce unnecessary complexity and bloated architectures. An Architect who can't code is not an architect, Period. No self respecting architect would never say no to coding.
  13. An Architect who can't code is not an architect, Period. No self respecting architect would never say no to coding.
    Totally agree. I think that any Java developer (well, any O-O developer, even in plain C) is primarily an architect. Being a developer, in the sense of someone who knows language syntax, packages and frameworks, without strong design skill, is a nonsense. Guido
  14. An Architect who can't code is not an architect, Period. No self respecting architect would never say no to coding.

    Totally agree.
    I think that any Java developer (well, any O-O developer, even in plain C) is primarily an architect.
    Being a developer, in the sense of someone who knows language syntax, packages and frameworks, without strong design skill, is a nonsense.

    Guido
    This goes to one of my strongly held beliefs. If you can write something down in a way that someone else can implement it without making any decisions on their own, you can could potentially execute that description as a program. The reality is that level of creating a program involves design. Any steps that do not involve design should be eliminated and I believe they will be over time. My belief is that we need to focus on building small groups of mixed experience/skill levels to attack problems. Bigger projects require collections of such groups with more fluid membership and one larger group. The current approach of stratification not only produces poor results but is make it hard for inexperienced programmers to learn from others.
  15. My belief is that we need to focus on building small groups of mixed experience/skill levels to attack problems. Bigger projects require collections of such groups with more fluid membership and one larger group. The current approach of stratification not only produces poor results but is make it hard for inexperienced programmers to learn from others.
    I think you've hit the nail on the head.
  16. My belief is that we need to focus on building small groups of mixed experience/skill levels to attack problems. Bigger projects require collections of such groups with more fluid membership and one larger group. The current approach of stratification not only produces poor results but is make it hard for inexperienced programmers to learn from others.


    I think you've hit the nail on the head.
    Well, thanks for seeing through my incredibly poor editing. I must have been distracted when I wrote that.
  17. The current approach of stratification not only produces poor results but is make it hard for inexperienced programmers to learn from others.
    Should be put in great evidence on TSS home page. Guido
  18. The foolishness of do-it-all[ Go to top ]

    First of all, I'd agree that there are often too many layers in any given architecture or there are too many levels of decision making in any given project. Once these things are in place, of course, you will need to work with them as long as they support a running system. And yes, accountability is important, but a modern IT environment will never work with a high degree of specialization (in our progams we show off what great guys we are too have achieved "separation of concern" yet in the real world we think it is evil??). But does anyone really believe you need to be a programmer and understand the *whole system* you are working on? A real world business system usually works with arounf 5-10 databases (different vendors), an application server cluster, a product someone bought that works on top of that (portal, business automation), a security infrastructure, a couple of web servers, various communication and execution paradigms (message driven, synchronous, file exchange, batch), backup strategies, failover strategies, operating systems, storage systems and don't get me started about external interfaces, devices (printers, scanners) and 3rd party applications. Anyone can be a good Java Programmer and a good C++ Programmer and a good Transact/SQL Programmer and a good PL/SQL Programmer and a good system Administrator ... hardly so. That said, someone who architects and designs a particular component of such a system should be well aware of the environment the component will run in and the side effects this component will have. A lot do (a). And a lot of programmer put instance variables in their Struts Actions (b). Both should be accountable of course. But if (b) happens (a) it is not necessary (b)s fault, especially not if the "architect" is from a different company than the developer or the poor chap is working in a matrix managed environment, so he can't even decently control the people that implement the specification. And one final word: In the real world, architecture and software design almost always looses against business drivers and deadlines.
  19. software design almost always looses[ Go to top ]

    The previous post gets to the nub of the problem. The fact that so called 'business drivers' and deadlines trump good design and good development is THE problem. I say 'so called' business drivers, because anyone who thinks that somehow the 'business' can be served by compromising on quality of development needs a brain transplant. If quality did not matter in a software project, then why do it at all? Fact is, development projects are motivated by a perceived business advantage, but there is a disconnect between those who don't understand that nothing is free and those who do the actual work. A complicating factor is the lower skill level today of most developers, due in large part to the outsourcing/offshoring trend, and that today's corporate culture doesn't value real experience and skill. The key concept to understand and fix is the slavish obsession with deadlines, and the incorrect perceptions of what constitutes cost and cost savings.