none
How to deal with when Project Management constraints the Architecture?

    Question

  • Hi guys,

     

    I'm not sure if this happened to you but I experienced this issue with certain frequency

     

    • You are assigned the role of architect for an upcoming project to be built (in other words and avoiding staying stuck on definitions, let's say that you'll be responsible of defining the solution architecture)
    • As usual, there are certain pre existing constraints (like storing data in the corporate database, accessing some information by bridging to the company mainframe, etc). What it's expected from you is architecting a solution to fulfill the project goal while contemplating those constraints
    • You start making some decisions on layers, you make some PoCs and select some components as bridges between layers or tiers (like an O/R-M to bridge the gap between the DAL and the business layer, etc)
    • Suddenly, either the project manager or any other authority in the IT staff (perhaps not directly involved with the project but an authority anyway) force you change some already taken decisions, leaving you little margin to maneuver

    Typical reasons I heard

    • "All data-access must be done through stored procedures and that framework you got just work with single SQL commands"
    • "No stored procedures allowed here as they put a risk on scalability"
    • "We can't incorporate that third-party framework as the project lacks of budget for the license"
    • "We can't incorporate that open-source framework as it lacks of formal support in any problem arises"
    • "It was just decided that any access to the mainframe and the database must necessary pass though the orchestrator we bought. I don't care if that makes roundtrips unnecessary slower: we spent a lot on it to just avoid it" (surely we've never heard something like this, have we? )
    • "..."

     

    Most of all, I must say that, thinking it coldly (and surely without the architect hat on), all reasons sound reasonable!! But how silly have you felt when your intellectual authority was just swiped out of your architecture diagram by someone with greater political authority?

     

     

     

    What should an architect do in these cases? I provide some examples below

    • Complying without further questions? (in that case, even if we won't be liable of any negative consequence derived of the decision we were forced to take, what happens with the moral of the project and our initial motivation to lead the architecture?)
    • Facing the upper levels in the hierarchy by demonstrating (via PoC, stress tests or any other "ad hoc" technique depending on the problem) they are wrong? Cool, if they accept, double win, but when they are still reluctant we are back in the previous bullet and, in the meanwhile: when to stop facing if the next project milestones enter in red zone?
    • Escaping forward by trying to find another project? (either in the same organization or not). If so, what about your illusion of being part of that company, that project and the career you were doing there?
    • ... (YOUR THOUGHTS HERE)

    In other words, how to deal with the tense relationship between we the architects and the management for the sake of the business goals (in last instance) we technologists must enable?

    Wednesday, May 07, 2008 2:34 AM

Answers

  • Diego,

     

    Excellent questions!

     

    Happens all the time, I agree.  Or at least people try it all the time.

     

    My questions would the constraint be due to a business situation, such as a lack of budget / timescale etc?  Is the contraint actually the politically powerful figure's attempt to solve the problem imposed by the business, and if so, does that person actually have the technical skills to make such a decision?

     

    Here we're in communication, facilitation, and negotiation mode.  I would say that the system should be a negotiation, during which if the architect proposed solution has reasons for being chosen, pros and cons, and the political figure's proposed solution has the same, then the selection of technology that fits the business best can be chosen.  If the situation is a who shouts loudest situation, then the whole process is flawed, and the architect is then not able to realistically do their job effectively.  Happens all the time though, often due to knee jerk reactions to historical problems.  A wise person told me never to ask questions that you don't already know the answers to.  If the architect doesn't have an reasonable argument to choose their solution over another solution, or is not able to communicate that effectively, then perhaps that is the best choice, since the architect possibly doesn't understand the propsed solution as well as they think?

     

    My personal view with regard to architects, is that the architect is in effect communicating the business strategy, and their requirements at any point in time.  Part of that role is to also point out that there is a more effective way to do things, in a persuasive, and understandable manner.  The job entails coming up with new ideas, new ways that the business could move forward, typcially from a strategy supported by the IT artifacts.  If the business cannot leverage any business value from that solution, then that is not the right solution to be pushing.

     

    If the architect is always overruled by the person who shouts loudest, sits next to the CEO, or is in some way more political than the architect, then perhaps the company is not taking the role of architect seriously, and the architect should look for a new job, and step aside for the political figure to make those decisions instead?

     

    Hope that helps,

     

    Martin Platt.

    Thursday, May 08, 2008 6:22 AM
  •  Martin Platt wrote:
    If the architect is always overruled by the person who shouts loudest, sits next to the CEO, or is in some way more political than the architect, then perhaps the company is not taking the role of architect seriously, and the architect should look for a new job, and step aside for the political figure to make those decisions instead

     

    When all that is reasonable fails, that too is my approach: leave to better shores.

     

    In fact, despite any responsibility for the obvious later disaster should go to who imposed those decisions, even that rarely happens and we still find ourselves under the pressure of that same powerful guy who keeps tapping at our shoulders each and every 5 minutes with a: have you finished yet!, so that, finally, we still are those to blame, in any case...

     

    One could then try to just keep the mouth as shut as possible, but what then becomes of personal and professional grouth, sense of fulfilment, etc. etc.?

     

    So, in the very end, when things go *that* bad, to me it becomes a sort of personal although professional thing, and I see no more reason not to simply say bye bye... not even need to bum the door, although that's funny in itself... Wink

     

    -LV

    Thursday, May 08, 2008 6:53 PM
  • Most of the time I was able to sway the sea of change.  Here are the things I have done in the past.

     

    First and foremost, as Architect, I believe it is my responsibility to know the person that makes executive decision on the project and develop communication means to that person directly or in-directly.  I know, Project Managers want to be the communication voice for the project, but I still find my way to the person that says 'Buck stops here'...

    Knowing that person, I was able to sway the decision towards what best fits for the project based on collective team's decision [Oh yeah, you need to have the team speaking the same language].

     

    I choose the battles I want to fight.  It is very important to know if I want to stick it in, I should believe in it right !!!

     

    There are times, even doing all these things, I have lost many battles.  I have lost a battle 4 years ago that was very near to my heart and I did not believe in.  The solution was brain child of CIO, who drank the salesperson koolaid from vendor.  I was young and dumb to quit the company.  Yes I said "young and dumb" to quit, because now in the past 4 years I am conditioned enough to understand that in every company there are things that I wont disagree and I am not bought into that.  But I cant be looking for a new job everytime that happens.  In the current company I work, I probably have more disagreements than I had in my previous organization.  Only this time, I am staying put, how long, I dont know.

    Friday, May 09, 2008 7:25 PM

All replies

  • Diego,

     

    Excellent questions!

     

    Happens all the time, I agree.  Or at least people try it all the time.

     

    My questions would the constraint be due to a business situation, such as a lack of budget / timescale etc?  Is the contraint actually the politically powerful figure's attempt to solve the problem imposed by the business, and if so, does that person actually have the technical skills to make such a decision?

     

    Here we're in communication, facilitation, and negotiation mode.  I would say that the system should be a negotiation, during which if the architect proposed solution has reasons for being chosen, pros and cons, and the political figure's proposed solution has the same, then the selection of technology that fits the business best can be chosen.  If the situation is a who shouts loudest situation, then the whole process is flawed, and the architect is then not able to realistically do their job effectively.  Happens all the time though, often due to knee jerk reactions to historical problems.  A wise person told me never to ask questions that you don't already know the answers to.  If the architect doesn't have an reasonable argument to choose their solution over another solution, or is not able to communicate that effectively, then perhaps that is the best choice, since the architect possibly doesn't understand the propsed solution as well as they think?

     

    My personal view with regard to architects, is that the architect is in effect communicating the business strategy, and their requirements at any point in time.  Part of that role is to also point out that there is a more effective way to do things, in a persuasive, and understandable manner.  The job entails coming up with new ideas, new ways that the business could move forward, typcially from a strategy supported by the IT artifacts.  If the business cannot leverage any business value from that solution, then that is not the right solution to be pushing.

     

    If the architect is always overruled by the person who shouts loudest, sits next to the CEO, or is in some way more political than the architect, then perhaps the company is not taking the role of architect seriously, and the architect should look for a new job, and step aside for the political figure to make those decisions instead?

     

    Hope that helps,

     

    Martin Platt.

    Thursday, May 08, 2008 6:22 AM
  •  Martin Platt wrote:
    If the architect is always overruled by the person who shouts loudest, sits next to the CEO, or is in some way more political than the architect, then perhaps the company is not taking the role of architect seriously, and the architect should look for a new job, and step aside for the political figure to make those decisions instead

     

    When all that is reasonable fails, that too is my approach: leave to better shores.

     

    In fact, despite any responsibility for the obvious later disaster should go to who imposed those decisions, even that rarely happens and we still find ourselves under the pressure of that same powerful guy who keeps tapping at our shoulders each and every 5 minutes with a: have you finished yet!, so that, finally, we still are those to blame, in any case...

     

    One could then try to just keep the mouth as shut as possible, but what then becomes of personal and professional grouth, sense of fulfilment, etc. etc.?

     

    So, in the very end, when things go *that* bad, to me it becomes a sort of personal although professional thing, and I see no more reason not to simply say bye bye... not even need to bum the door, although that's funny in itself... Wink

     

    -LV

    Thursday, May 08, 2008 6:53 PM
  • Im my opinion It is important to understand if the reason expressed by others has some reason to exists  and try to discuss it. For example

    "We can't incorporate that third-party framework as the project lacks of budget for the license"

    Obviously this is indeed a reasonable request, the budget is important and the architect can show that  the cost of the framework is actually saving more money in development time or in other areas. Sometimes project manager look at external licenses only seeing the “license cost” and not the benefit in developing time. This example is a good ground for discussion. The real problem is when there are some technical constraints that seemed to have no reason, for example

    "No stored procedures allowed here as they put a risk on scalability"

    This is not a good constraint, especially when it come from people with weak technical knowledge. And if it is not possible to avoid it even with good argumentation (PoC, StressTest, etc) it is time to looking for better place to work.  I completely agree with Ludovico. 

    Alk.

    Friday, May 09, 2008 2:40 PM
  •  Alkampfer wrote:

    Im my opinion It is important to understand if the reason expressed by others has some reason to exists  and try to discuss it. For example

    ...

    "No stored procedures allowed here as they put a risk on scalability"

    This is not a good constraint, especially when it come from people with weak technical knowledge. And if it is not possible to avoid it even with good argumentation (PoC, StressTest, etc) it is time to looking for better place to work.  I completely agree with Ludovico. 

    Alk.

     

    And I completely agree with you there. Indeed, I have just tried to describe my approach to the worst case scenario.

     

    What's, in a sense, "sad" is that such worst case scenario is by far the most widespread. As they told me at a recent contract I got, "we are customer driven", to which I answered "that's perfect as far as I am concerned", to later discover that they actually meant "we are account/pm driven, and don't give a dime to engineering practices and whatever technical and even conceptual you might ever like to throw in, least to say to any form of serious analysis of requirements (and, should you ever think you need a direct relationship to the so called (not by them) domain experts, well: just forget about it, here is the requirements, and that's it!)." The result is what I simply call: *permanent emergency*.

     

    In fact, the more I think of it, the more I am convinced it is such very poor understanding of what "requirements" and "analysis" mean that is at the root of most if not all of the problems... And then (pardon a simple slogan here) we can have architecture on top of the project, despite any rigorous definition of quality!

     

    -LV

    Friday, May 09, 2008 3:00 PM
  • Most of the time I was able to sway the sea of change.  Here are the things I have done in the past.

     

    First and foremost, as Architect, I believe it is my responsibility to know the person that makes executive decision on the project and develop communication means to that person directly or in-directly.  I know, Project Managers want to be the communication voice for the project, but I still find my way to the person that says 'Buck stops here'...

    Knowing that person, I was able to sway the decision towards what best fits for the project based on collective team's decision [Oh yeah, you need to have the team speaking the same language].

     

    I choose the battles I want to fight.  It is very important to know if I want to stick it in, I should believe in it right !!!

     

    There are times, even doing all these things, I have lost many battles.  I have lost a battle 4 years ago that was very near to my heart and I did not believe in.  The solution was brain child of CIO, who drank the salesperson koolaid from vendor.  I was young and dumb to quit the company.  Yes I said "young and dumb" to quit, because now in the past 4 years I am conditioned enough to understand that in every company there are things that I wont disagree and I am not bought into that.  But I cant be looking for a new job everytime that happens.  In the current company I work, I probably have more disagreements than I had in my previous organization.  Only this time, I am staying put, how long, I dont know.

    Friday, May 09, 2008 7:25 PM
  •  LudovicoVan wrote:

     

    In fact, the more I think of it, the more I am convinced it is such very poor understanding of what "requirements" and "analysis" mean that is at the root of most if not all of the problems...

     

     

    I believe you really got the problem!! I really agree with this, too often requirements and analysis are really the root of many problems.

     

    Alk.

     

    Monday, May 12, 2008 9:34 AM
  • Hi All,

     

    I just found this forum and its great to know there are others who share the same concerns I have.  This particular thread I am living through right now.  I work for a top tier investment bank and what tends to happen in our environment that provides challenge is the speed of change.  Typically we dont have the luxury of mapping out a full architecture, and we are restricted by aggressive timelines and product deployments.

     

    The way that I am finding to get around it, is to immediately map out the infrastructure components required for the implementation, and focus on process-flow dependency ( if I make this change what else in the infrastructure will be impacted ), inter-connectivity ( understanding how these components need to communicate together, and how the entire solution needs to communicate with the rest of the infrastructure ), security, administration, and management.

     

    I find that focusing on these key areas get the majority of the questions answered to move forward, allow us to test specific components for validity quickly, and the ability to provide a support model once implemented - which helps when handing off to Operations and Off-shore support teams.

     

    My approach is a bit more pratical simply from experience, but it is well based on the principles of Enterprise Architecture I have picked up over the years.

     

    I am interested in sharing ideas with everyone to get a better idea of how to improve my process

     

    Thank you,

     

     

    Monday, May 12, 2008 6:51 PM
  • For me it's very similar to the challenges faced in the majority (if not all) parts of a project and why 'Agile' has become so popular, i.e. do people really know what they want at the start? I think it was Martin that mentioned the magic word of 'negotiation' and it should be a continuous process. So, as already mentioned, in the framework example you'd discuss the pro's & con's including financial concerns and maybe even change the decision as more about the real problem is discovered. Also borrowed from the Agile community (but certainly not exclusive to it) is, as Christopher posted, the simple concept on focusing on the 'important' problems first. Of course that's a discussion in itself (riskiest problem first, best feature for the biz', etc). For me the arch' isn't a concrete decision that is made before the coding starts and that does not change through the life of a project. Obviously you want to get it as correct as possible but it's not sacred.

    I'd also agree that you need to be a political animal too but if someone with the ear of the decision maker is rail-roading their choices then I guess it comes down to either making the best of a bad deal or voting with your feet - not always easy to do. In theory it's better to have the decisions made with the stakeholder team but it doesn't always work if people aren't willing, for a variety of reasons, to contribute. Also, to paraphrase, you run this risk of creating a camel arch' by committee so it does tend to come down to a couple of people making the decisions. - hopefully one of those is the arch'!


    Tuesday, May 13, 2008 6:13 AM
  • Thanks all you guys for your valuable answers

     

    I feel that even when all alternatives to tackle the personal problem imply at the same time accepting some loss, you must just choose the best you think (hopefully wiselly, but you won't know the veredict until after choosing something and getting the consequences ) and turn the page as soon as possible

     

    In certain way is similar to those situations, when playing chess, where you must decide either by capturing the queen but sacrifycing the tower as an aftermath, or by forcing the other's king a step beyond towards the mate (still not guaranteed) but loosing the bishop as a consequence of the attempt. Surely the long term goal (winning the match) should remain on top of local incidents like loosing some key piece in the meanwhile, and the art behind our science is how to keep our blood cold enough (without killing anyone in our way ) in order to clearly determine what are long-term goals, what contextual issues

     

     

     

    By the way! I was reading pkr2000 comments on Agility and made me remember what happened to me when I tried to apply something like that in a context similar to the one of this thread. I don't want to contradict pkr2000 as what it happened to me not necessarily should happen to everyone else. Actually what I have to discuss about that is wider. So wide that I decided to open another forum thread, as discussing on that here would disgregate the original topic of this thread

     

     

     

    Let's grab some coffee and meet on "Evangelizing in Companies With Long-Term Culture and Habits"

    Wednesday, May 14, 2008 12:33 AM
  • Christopher Westpoint wrote:

     

    > The way that I am finding to get around it, is to immediately map out the infrastructure components required for the implementation, and focus on process-flow dependency ( if I make this change what else in the infrastructure will be impacted ), inter-connectivity ( understanding how these components need to communicate together, and how the entire solution needs to communicate with the rest of the infrastructure ), security, administration, and management.

     

    You have not mentioned _the_ one factor that really counts, that is "user needs", better known as explicit or *conceptual* requirements, or otherwise business analysis. As an Architect, I believe you are correct in focusing in the implicit or *technical* requirements, but if your goal is overall improvement, not only of the process but also of the project and product, the conceptual requirements should go on top of the list. For a more rigorous approach, just confront the ISO definition of Quality, which is a great reference point.

     

    > I am interested in sharing ideas with everyone to get a better idea of how to improve my process

     

    I hope this gives at least a more clear grasp of what's at stake. To paraphrase from pkr2000: hopefully one of them (hats) is the Analyst!!

     

    -LV

    Wednesday, May 14, 2008 5:03 PM
  • Re: Business Analyst (BA), I think it might be interesting to start a new thread on that because in my experience although the BA is certainly a very important stakeholder they are conceptually treated as one of the clients. That is to say they are one the inputs for an arch' and developer. In a more...shall I say waterfall...method then they'd become the go-between. It would be interesting to see how others interact with BAs.

     

    Wednesday, May 14, 2008 5:27 PM
  • pkr2000 wrote:

     

    > in my experience although the BA is certainly a very important stakeholder they are conceptually treated as one of the clients.

     

    That's indeed a big mistake...

     

    > That is to say they are one the inputs for an arch' and developer. In a more...shall I say waterfall...method then they'd become the go-between. It would be interesting to see how others interact with BAs.

     

    They are not "one of the inputs", they are the *primary* input in the strict sense. No Analysis, no Project.

     

    You should maybe keep in mind Analysis is on the conceptual side, the rest is technical.

     

    WHAT are you going to build? Oh yes, you are for the Architect on top... that's *the* big mistake, not better than PM on top, and disastrous alike...

     

    -LV

    Wednesday, May 14, 2008 5:35 PM
  • I don't think that is absolutely true. The team of people includes a BA and they certainly have an input but it should include various customers representatives, "non-functional" heads, etc. For me a BA is excellent at teasing out the core/majority of the issues but nothing beats getting the whole team together. As I said in another post, I don't believe in someone over another approach. That's why I think that perhaps you could start a dedicated thread on the subject.

     

    Wednesday, May 14, 2008 5:50 PM
  •  pkr2000 wrote:

    I don't think that is absolutely true. The team of people includes a BA and they certainly have an input but it should include various customers representatives, "non-functional" heads, etc. For me a BA is excellent at teasing out the core/majority of the issues but nothing beats getting the whole team together. As I said in another post, I don't believe in someone over another approach. That's why I think that perhaps you could start a dedicated thread on the subject.

     

     

    I'd rather suggest you open a dedicated thread with no subject.

     

    As to the relevance of my points, I am criticizing - and very hard - your concept of Architecture as well as the role you seem to assign it: I BELIEVE IT IS THE GREATEST SOURCE OF THE SOFTWARE DEVELOPMENT PROBLEMS!!! And it is Architecture.

     

    Got it?

     

    -LV

    Wednesday, May 14, 2008 5:55 PM