What does a 'Solutions Architect' really do?

Home

News: What does a 'Solutions Architect' really do?

  1. What does a 'Solutions Architect' really do? (56 messages)

    I've just accepted a new role: "Solutions Architect." I was working as Systems Architect, but I wonder: what does a Solutions Architect really do? If you take a look on the Internet, you are able to see that the title isn't old. It was created/appeared a few years ago. I believe that it really came to the world on the end of 2005. Before that we had a lot of other Architects that we still have, such as Infrastructure Architect, Software Architect, Software Architect, Systems Architect, Enterprise Architect and others. I compiled some opinions about what some people think the Solutions Architect does.
    The Solutions Architect is responsible for the design or one or more applications or services within an organization, usually within the scope of a division... The Solutions Architect works with the Enterprise Architect for strategic direction (both conforming to, and helping to define). ... A 21st century title for an IT consultant or systems analyst. It implies that the person is very capable in problem solving. Like a systems analyst, a solutions architect must have a balanced mix of technical and business skills. ...
    There are more definitions, but what do you think? Is it only one more role/job description?

    Threaded Messages (56)

  2. Hm...same job as a Senior Developer, but with more pay?
  3. You now write less code. Business needs technical types to make decisions on architecture and to build IT infrastructure. Leave the coding to the developers but don't forget what you've learned. Listen a lot, and when you speak be honest and correct. David Whitehurst
  4. chatbox[ Go to top ]

    To me this kind of contentless "please discuss" post is not why I visit TSS. Is TSS running out of news?
  5. Just curious[ Go to top ]

    Forgive me for asking, but why do you accept a new role from your employer if neither one of you knows its job description?
  6. Re: Just curious[ Go to top ]

    Forgive me for asking, but why do you accept a new role from your employer if neither one of you knows its job description?
    and more to the point why the hell did this company employ you if you don't know anything about the role?
  7. Re: Just curious[ Go to top ]

    Forgive me for asking, but why do you accept a new role from your employer if neither one of you knows its job description?

    and more to the point why the hell did this company employ you if you don't know anything about the role?
    Maybe they don't know anything about the role, either? Does ANYONE have a well-defined role these days? Where are these mythical employers?
  8. Re: Just curious[ Go to top ]

    Forgive me for asking, but why do you accept a new role from your employer if neither one of you knows its job description?

    and more to the point why the hell did this company employ you if you don't know anything about the role?


    Maybe they don't know anything about the role, either?

    Does ANYONE have a well-defined role these days?

    Where are these mythical employers?
    I have the same title at my current job as I did in my last job. My compensation, responsibilities, and expectations are vastly different. To your point, I've often had a well-defined position description but it's rarely accurate. So to both the original question and to people who have responded, you can't make any generalizations about these titles. There is no consistent industry-wide standard. Not even for the terms 'developer' and 'programmer'. What does "solution architect" mean? Well, if your boss doesn't know, and you don't know, you will need to define your role. And, it is pretty scary that your employer is putting you into a role without any clear understanding of what that role means. One might think (naively, I suppose) that it would make more sense to figure out what the organization needs and try to fill that role instead of picking an arbitrary title, finding a definition for it and doing whatever that is. It's also important to ignore titles on resumes. They are useless unless you worked at that company and know what those titles mean. A lot of the cynicism around the 'architect' role is that it's often given to people who have never written a line of code professionally. Expecting developers to respect the advice of someone who has never done any development is like expecting a basketball team to listen to a coach that's never played basketball. This is especially true when these non-developer architects try to push tools designed for non-developers on developers. Personally I think it's a shame that this is what architect has come to mean because it should be someone who gets both the big picture and the challenges of the developers.
  9. NCA[ Go to top ]

    ...A lot of the cynicism around the 'architect' role is that it's often given to people who have never written a line of code professionally...
    Ok, James... now we've all heard of the NCA or "Non-Coding Architect" before, but this one is something I've never personally run across. Are you saying you've actually encountered architects who've never cut production code IN THEIR LIVES? I'm not so much doubting you as trying to find out if these mythical NEVER-CODED architect 'creatures' actually exist. I've met architects that I ACCUSED of never having cut production code, but... I never really BELIEVED that about them. (well, ok, maybe one or two, but that's another story entirely)
  10. Re: NCA[ Go to top ]

    ...A lot of the cynicism around the 'architect' role is that it's often given to people who have never written a line of code professionally...


    Ok, James... now we've all heard of the NCA or "Non-Coding Architect" before, but this one is something I've never personally run across. Are you saying you've actually encountered architects who've never cut production code IN THEIR LIVES? I'm not so much doubting you as trying to find out if these mythical NEVER-CODED architect 'creatures' actually exist. I've met architects that I ACCUSED of never having cut production code, but... I never really BELIEVED that about them.

    (well, ok, maybe one or two, but that's another story entirely)
    I sit within a stone's throw of a guy that flat told me that he's not a developer and hasn't done development outside of school. He's actually a really smart guy so he's kind of a bad example. But, when someone is recommending tools and techniques, I think most developers will have a hard time accepting that from someone who isn't one of them. It's personally difficult for me to understand how someone who isn't a user of a tool can be sure it's the right one. There are also the architects that never were good developers or are so far removed they've lost the feel for it. Everything seems so easy from 10,000 ft. The real problem is that architects say "do this" and the developers say "won't work" and it never seems to be completely resolved.
  11. Re: NCA[ Go to top ]

    The real problem is that architects say "do this" and the developers say "won't work" and it never seems to be completely resolved.
    Hi James, I'd second that. I think the whole architect thing is/was yet another way to marginalise (eliminate, dumb down, dis-empower) programmers. As allways it was the vendors advocating to management that they need architects. In the same way they told the managers that they could save a load of money on programmers if they adopted middleware tools and an "enterprise technology stack". If you do this then the job is almost done, and those programmers (coders) become insignificant :^) No one wants to touch code. Every one wants to draw square boxes and straight lines on a white board. Yet it is the code that counts, and programmers still have to write the stuff dispite what ever managers/architects and vendors may want to think. Paul.
  12. Re: NCA[ Go to top ]

    No one wants to touch code. Every one wants to draw square boxes and straight lines on a white board. Yet it is the code that counts, and programmers still have to write the stuff dispite what ever managers/architects and vendors may want to think.
    I think there's definitely a higher level of design that must take place, especially in an environment like the one I work in now. I can't really place the blame squarely on either developers or architects. A lot of developers are very down in the weeds and are only thinking about the things they are working on and not how they fit into the larger picture. Some developers are the 'just tell me what to do' type. The architects are looking at the big picture (how successfully is another topic) but lack the ability to explain how to implement that vision and/or don't realize when it makes no sense or is just plain dumb. Even if the architect is right, how can they hope to resolve a dispute with a developer that is disagreeing with them? The best way to show someone that something will actually work is to demonstrate it. A lot of architects can't do that. All they can say is that they think it should work or that it's a 'best practice' they read somewhere.
  13. Re: NCA[ Go to top ]

    No one wants to touch code. Every one wants to draw square boxes and straight lines on a white board. Yet it is the code that counts, and programmers still have to write the stuff dispite what ever managers/architects and vendors may want to think.


    I think there's definitely a higher level of design that must take place, especially in an environment like the one I work in now.

    I can't really place the blame squarely on either developers or architects. A lot of developers are very down in the weeds and are only thinking about the things they are working on and not how they fit into the larger picture. Some developers are the 'just tell me what to do' type.

    The architects are looking at the big picture (how successfully is another topic) but lack the ability to explain how to implement that vision and/or don't realize when it makes no sense or is just plain dumb.

    Even if the architect is right, how can they hope to resolve a dispute with a developer that is disagreeing with them? The best way to show someone that something will actually work is to demonstrate it. A lot of architects can't do that. All they can say is that they think it should work or that it's a 'best practice' they read somewhere.
    Amen Guido
  14. Re: NCA[ Go to top ]

    I think there's definitely a higher level of design that must take place, especially in an environment like the one I work in now.

    I can't really place the blame squarely on either developers or architects.
    I agree. When I was an architect, I always wrote code. I would produce a working prototype as a proof of concept before usually with the help of a developer, before imposing technology on development team. I was never satisfied to take someone else's word for it or rely on something I read.
    A lot of developers are very down in the weeds and are only thinking about the things they are working on and not how they fit into the larger picture. Some developers are the 'just tell me what to do' type.

    The architects are looking at the big picture (how successfully is another topic) but lack the ability to explain how to implement that vision and/or don't realize when it makes no sense or is just plain dumb.

    Even if the architect is right, how can they hope to resolve a dispute with a developer that is disagreeing with them? The best way to show someone that something will actually work is to demonstrate it. A lot of architects can't do that. All they can say is that they think it should work or that it's a 'best practice' they read somewhere.
    I think we continually under estimate the difficulty of software development. I just don't think you can easily compartmentalize like this. Things are just too complex and interdependent. Whilst coding I find myself doing a bit of business analyis, system analysis, some system design, programming, architectng, then jumping back to analysis all within a few minutes. The truth is we all do all these things all the time. I just think these roles are false. Programmers should be forward thinking and part of their job should be investigating new technology on an ongoing basis. The reason why I gave up being an architect is because I felt I was beginning to lose touch with what matters. You just don't have a feel for the pain points unless your having to deal with them on a daily basis. I just don't think an architect is in a position to get real feedback on the consequences of his decisions, and because of this he is likely to make poor choices without ever knowing. Paul.
  15. Re: NCA[ Go to top ]

    I think we continually under estimate the difficulty of software development.
    Everyone but the person that's trying to make it work and sometimes even that person thinks they are done when they get the 'happy path' working for most of the requirements.
    I just don't think you can easily compartmentalize like this. Things are just too complex and interdependent. Whilst coding I find myself doing a bit of business analyis, system analysis, some system design, programming, architectng, then jumping back to analysis all within a few minutes. The truth is we all do all these things all the time.

    I just think these roles are false. Programmers should be forward thinking and part of their job should be investigating new technology on an ongoing basis. The reason why I gave up being an architect is because I felt I was beginning to lose touch with what matters. You just don't have a feel for the pain points unless your having to deal with them on a daily basis.

    I just don't think an architect is in a position to get real feedback on the consequences of his decisions, and because of this he is likely to make poor choices without ever knowing.
    Exactly right. I was telling someone the same thing a while back. It's the same reason that bringing in contractors for new development usually a bad idea. If you never have to suffer the consequences of your choices you are more likely to make bad decisions or learn from your mistakes. This is called 'moral (or morale) hazard' in the insurance business. It's why you aren't likely to find a car insurance company that's willing to give you a $0 deductible on your car insurance. Personally I think that there are definitely different classes of developers and they are (very) roughly aligned with experience in that there are certain levels you can't reach without having been through the lower levels. There's nothing new about this idea. It's how the world has worked for millennia. You don't become a detective without ever walking a beat. And I also agree that in these levels, your responsibilities are basically the same. It's just the scope that changes. You learn how to build something small and then you build something bigger. You work with people that already know and learn from them and try to improve on what they teach you. This isn't rocket science. People who believe these processes don't apply to software remind me of the 'new economy' people who were sure that tech stocks could sell at higher and higher P/E ratios forever in 1999.
  16. Re: NCA[ Go to top ]

    My cousin is an iron worker. Generally he works on large building projects. Onetime I was complaining about some of the nonsense I see in the field - people with no field experience trying to lead people with a lot of experience - and he said it's the same in construction. The site manager has arguments all the time with architects. Generally, the architect hands over blue prints and the site manager looks them over, pointing out where different features will break building codes, causing inspection to fail, cost overruns, etc. Often enough, the architect goes off in a huff saying, "Just find a way to make it happen". That said, a friend of mine is an architect but he also picks up tools and joins in the building process periodically to keep his hands in it. I think architects can be valuable, but they need a love for all phases of the building process. They should have an attitude that getting their hands dirty is fun, not a chore. When I entered the field (early 90's) Sr. Developers were usually the designers. The developer had knowledge of both the business and technologies that were relevant to it through years of experience with both. Now the design aspect is being split into a design specialist role called an "architect". It's another phase of industry trying to figure out how to make software development manageable. My belief is that money would be better spent having levels of Developer in each organization - cut out architect and any other splinters off the Developer tree. Setup developers into novice, intermediate, and senior levels with a career development and responsibility path along the way. PAY the senior developers as well as you would pay senior management because they will ultimately be responsible for the information your business uses.
  17. Re: NCA[ Go to top ]

    I think there's definitely a higher level of design that must take place, especially in an environment like the one I work in now.

    I can't really place the blame squarely on either developers or architects.

    I agree. When I was an architect, I always wrote code. I would produce a working prototype as a proof of concept before usually with the help of a developer, before imposing technology on development team. I was never satisfied to take someone else's word for it or rely on something I read.


    A lot of developers are very down in the weeds and are only thinking about the things they are working on and not how they fit into the larger picture. Some developers are the 'just tell me what to do' type.

    The architects are looking at the big picture (how successfully is another topic) but lack the ability to explain how to implement that vision and/or don't realize when it makes no sense or is just plain dumb.

    Even if the architect is right, how can they hope to resolve a dispute with a developer that is disagreeing with them? The best way to show someone that something will actually work is to demonstrate it. A lot of architects can't do that. All they can say is that they think it should work or that it's a 'best practice' they read somewhere.

    I think we continually under estimate the difficulty of software development. I just don't think you can easily compartmentalize like this. Things are just too complex and interdependent. Whilst coding I find myself doing a bit of business analyis, system analysis, some system design, programming, architectng, then jumping back to analysis all within a few minutes. The truth is we all do all these things all the time.

    I just think these roles are false. Programmers should be forward thinking and part of their job should be investigating new technology on an ongoing basis. The reason why I gave up being an architect is because I felt I was beginning to lose touch with what matters. You just don't have a feel for the pain points unless your having to deal with them on a daily basis.

    I just don't think an architect is in a position to get real feedback on the consequences of his decisions, and because of this he is likely to make poor choices without ever knowing.

    Paul.
    I don't think yours is a very popular position among architects. I wouldn't worry too much. +1000 Guido P.S. I always thought that a Java developer (the one who knows the language syntax,library etc with someone else telling which class does what) is a non-sense. In OO approach there are continous design choices. It is impossible to write reasonable Java code without basic OO analysis/design and strong concurrency knowledge. And, nowadays, without ORM principles (not JPA/JDO or hibernate, those are tools) or DOC (again not RPC/CORBA/RMI - OK, even SOAP - ).
  18. Re: Just curious[ Go to top ]

    It's also important to ignore titles on resumes. They are useless unless you worked at that company and know what those titles mean.
    +1
    A lot of the cynicism around the 'architect' role is that it's often given to people who have never written a line of code professionally. Expecting developers to respect the advice of someone who has never done any development is like expecting a basketball team to listen to a coach that's never played basketball.
    Though construction workers would respect an able architect even if that architect never actually built a house.
    This is especially true when these non-developer architects try to push tools designed for non-developers on developers.
    That indeed is sad. To their defense, every tool vendor out there encourages this view, and I even had a bunch of teachers in college trying to discourage me from going for a programmer career as they thought programmers would be replaced by business people with great tools pretty soon. Heck, if you look at J(2)EE and how people often put the focus on tooling and prefer standardization over just good products, you can even say that many programmers themselves are guilty of trying to dumb down development. Personally I think it's a shame that this is what architect has come to mean because it should be someone who gets both the big picture and the challenges of the developers. Yes. What the naysayers miss is that there are actually plenty of companies out there with tens to hundreds of systems that need to evolved, connected, etc, and that Joe-programmer-on-system-X-or-Y is probably not the best person to be in charge of that. It actually makes sense to have people to keep track of the big picture; if your daily job is to implement one or two such systems it is easy get lost in details, and there are only so many hours in a day. In a next thread, we could ask architects and analysts what they think of the average programmer. My hunch for key words: 'short visioned', 'squabbly', 'likes shiny new tools and frameworks', 'business matter ignorant', 'quits when projects get into trouble', and so on. I'm just guessing since I am one of these programmers :-)
  19. I have been following the threads with great interest. Here's my spiel -

    10 years ago we did not have 'Architects' in the IT landscape - yet many systems were successfully implemented.

    So in my opinion, the 'Architect' role is really a repackaging of skills that were prevalent before, like:

    > Business Proposals & Business Cases

    > Requirement Analyses

    > Systems Analyses & Design

    > Functional & Interface Specifications

    To do these roles well, you often had to move between the 10,000ft view and the programmer (code) level views. You had to design solutions which fit in and answered a range of questions, both technical and business related.

    In the 21st century, the IT landscape is radically different. One of the main challenges is that proprietary systems must now inter-connect smoothly with all kinds of devices and applications. Besides the internet, we have all the connectivity via mobile devices. So the Architect must be across a range of different technologies & messaging software AS WELL AS provide process solutions that work for the business.

    I would not have much respect for an 'Architect' who fails to understand any of these views, especially the developer's. 

    I still think 'Architect' is just a classier name for a repackage of roles that were always done in IT.  It's not something totally new.    

  20. Re: Just curious[ Go to top ]

    Hi Raul, If you read my post you will figure out that I know enough about that job and I think that I'm doing it very well. By the way, what you know about that? Adilson Dias
  21. Hi Rob, Could you give me your definition for that role? I presume that you know it very well. Thanks, Adilson Dias
  22. Hi Rob,
    Could you give me your definition for that role? I presume that you know it very well.
    That would seem to be a pretty baseless assumption. It definitely doesn't follow from the statement he made.
  23. easy[ Go to top ]

    They do the same things the Enterprise Architect and system analysts do - nothing.
  24. Re: easy[ Go to top ]

    They do the same things the Enterprise Architect and system analysts do - nothing.
    I beg to differ.. They spout the buzzwords of the year and make glossy powerpoints that include them. I once got the advice from a solutions architect that the secret is to make the diagrams in pastelly colors, no one will question the soothing glow of pastelly boxes.
  25. Re: easy[ Go to top ]

    They do the same things the Enterprise Architect and system analysts do - nothing.


    I beg to differ.. They spout the buzzwords of the year and make glossy powerpoints that include them.
    I once got the advice from a solutions architect that the secret is to make the diagrams in pastelly colors, no one will question the soothing glow of pastelly boxes.
    P.S. It is mandatory that a solution architect never, repeat with me, never verifies that the puzzle pieces on the powerpoint really works together (and with which effort) and really fit in the specific case. And must blame on the designers/developers unable to understand the beauty and perfection. Be prepared for you new job. Guido
  26. Re: easy[ Go to top ]

    The main goal of a solution architect is to feed his/her ego with the minimum useful work possible. The title helps. (note, there aren't any 'solution architects' in jbilling. Egos have to be fed some other way). Paul Casal Sr Developer jbilling.com The Enterprise Open Source Billing System
  27. Just a new HR title to justify higher pay[ Go to top ]

    Well in every company there are levels and with each level there is a pay package range associated. Good talent is expensive to retain in market where demand exceeds supply. So HR will always keep such titles up there sleeve to justify reason for higher pay package for an individual. I have friends hired as Sr. Manager who still do day to day work as Sr. Developer. :-)
  28. Destroys the design[ Go to top ]

    It's part of a movement away from proper design and long term survival of systems over to "as long as there is a solution that works we are more than content". Her at least they like to call that something with "Solution" instead of system or whatever.
  29. Solution Architect is commonly seen with companies/vendors that have professional services (consultant) divisions. The Solution Architect typically architects a client solution using a vendor's technology stack. If you invite consultants from, say, for discussion, BEA, to your company to assist with the design and development of a system, you can expect the Sol. Arch. from BEA to pose a solution that is grounded in the BEA technology stack. In its most cynical form, the Solution Architect is weilding his/her parent company's hammer - so problem he/she sets out to solve looks like a nail. ;-)
  30. Re: Destroys the design[ Go to top ]

    Many people have different names for generally the same person... system architect, systems analyst, senior developer, technical lead. Though I do think the lead on a decent size project is going to be pretty much removed from the coding aspect of it, this individual *must* have a strong background in programming and it is probably a good idea that they do some coding on the project they're currently on. There's definitely a need for senior developers who can speak both business and technical people. And these people (generally speaking) should be paid more than those who can't. I think a lot of these new terms that do not mention the word programmer or developer is a result of businesses viewing pure coders as replaceable assets that can be easily outsourced. The old 'computer programmer' job title is avoided like the plague. My 2c. Mike
  31. I hope you don’t take to heart the very sad comments posted here. Enterprise Architects are responsible for aligning the IT investment with the business strategy so that the enterprise gets the most out of its IT expenditures. There is a lot of planning involved but also a lot of high level design and requirements packaging. Among the products of enterprise architecture may be reference architectures which provide you with exemplary (as in a “best practice” sample) solutions for problem types, e.g. document management, case management, domain services, etc. that employ the technology standards (e.g. products) your organization has adopted. Solution Architects on the other hand have to guide the architecture, design and to a lesser extent, implementation of the stuff that actually gets built. They produce concrete architectures, sometimes by drawing from the reference architectures - adding details, combining them, and otherwise working them into viable solutions. Sometimes reference architectures are derived from concrete architectures by the way. In either case (derived or created), many of the reference architectures are actually defined by solution architects, not enterprise architects. The role of the solution architect is to balance a workable real world solution with what is in the long term best interests of the enterprise as a whole – what the enterprise architecture has defined. They also provide an important loop back to the enterprise architecture that helps keep it grounded. As most of us know, enterprise architects sometimes lose touch and imagine things that aren’t feasible so it’s important that the solution architects provide them the ground truthing they need to improve their products and plans. A challenge you’ll face is that you will have to navigate project managers who think they are technical, enterprise architects who have a dream, and worst of all, sarcastic, condescending, know-it-all developers with tunnel vision who think they are “artistes” designing a work of art instead of a functional, maintainable service. They will all try to blame you for their problems and shortcomings, so strike first. Good luck.
  32. Well put. As in any role... you will get people that do the job well and add value, and those that are a waste of space. How I explain solution architects to folks is to think "design lead" for an enterprise scale project. From the conceptual design down to the nitty-gritty implementation issues. To be a good solution architect you must have a significant background with successful hands-on design & development experience across a broad range of products, technologies & methodologies. A solution architect must be as good a coder as he is on the white board (even though you don't get to do much coding). You must also be a good leader (not dictator). A solution architect should effectively become the go-to guy for many issues that crop up in the project... so if you don't know the business, project management as well as other technical bits like SCM... you shouldn't be a solution architect. In our organization, solution architects focus on the software side of architecture (EAI, SOA, etc.). Technical architects focus on the infrastructure/hardware side. But of course to be effective at either, you have to know something about the other. Having said that, good architects are even more rare than good project managers. ;-)
  33. Solution vs Data Architect[ Go to top ]

    I hope you don’t take to heart the very sad comments posted here.

    Enterprise Architects are responsible for aligning the IT investment with the business strategy so that the enterprise gets the most out of its IT expenditures. There is a lot of planning involved but also a lot of high level design and requirements packaging. Among the products of enterprise architecture may be reference architectures which provide you with exemplary (as in a “best practice” sample) solutions for problem types, e.g. document management, case management, domain services, etc. that employ the technology standards (e.g. products) your organization has adopted.

    Solution Architects on the other hand have to guide the architecture, design and to a lesser extent, implementation of the stuff that actually gets built. They produce concrete architectures, sometimes by drawing from the reference architectures - adding details, combining them, and otherwise working them into viable solutions.
    Sometimes reference architectures are derived from concrete architectures by the way. In either case (derived or created), many of the reference architectures are actually defined by solution architects, not enterprise architects.

    The role of the solution architect is to balance a workable real world solution with what is in the long term best interests of the enterprise as a whole – what the enterprise architecture has defined. They also provide an important loop back to the enterprise architecture that helps keep it grounded. As most of us know, enterprise architects sometimes lose touch and imagine things that aren’t feasible so it’s important that the solution architects provide them the ground truthing they need to improve their products and plans.

    A challenge you’ll face is that you will have to navigate project managers who think they are technical, enterprise architects who have a dream, and worst of all, sarcastic, condescending, know-it-all developers with tunnel vision who think they are “artistes” designing a work of art instead of a functional, maintainable service. They will all try to blame you for their problems and shortcomings, so strike first.
    Good luck.

    I agree with the points made about Architects, especially that they are "21st century" repackaging of Systems Analyst/Designer skills. But there is one big dimension that has not been exposed as yet. In contemporary IT projects, the solution is generally much broader and encompasses technologies such as internet/mobile/pda access into mission-critical applications; as well as catering to the vast range of user-accesses afforded by the internet. The web-based solution may also cater to a whole gamut of people, such as those with disabilities/special needs and often be multi-lingual.

    So the Solution Architect has now to potentially address and deal with design issues which, say a decade ago, a Systems Analyst/Designer would not worry about. This may not apply to the same extent in all projects but the business stakeholders will generally want a solution that caters across this whole spectrum.

    I am often asked "Are you a Solution or a Data Architect?" Come on - you can't be a Solution Architect without knowing enough about the Data side of things! What can a Solution Architect do if s/he does not understand the data solution?

         

  34. In my experience they come in pairs. They are usually consultants working for a vendor that wishes to push more of its products on the customer. The job of the first is to be able to talk like he knows both the business and the technology, at least to business-side people. The business side folks often really like him, and sometimes the tech folks to do, because he will periodically crucify his own companies product development organization for being moronic...and then for a price in the low seven figures offer what may be a workaround. His partner does all the dirty work. He knows enough about the business to not get completely lost, but is generally a gear head who just wants to make software work. His job is to nod at everything his partner says, and then work billed/uncompensated overtime making it real. He does this while his partner goes out for dinner and cocktails with the customer team. In unfortunate cases, especially with new deployments, both individuals work long hours trying to make the words of Sales Consultants real. Sometimes "solution architect" means "programmer who can clearly speak English and at times is co-located with the customer."
  35. I've just accepted a new role: "Solutions Architect." I was working as Systems Architect, but I wonder: what does a Solutions Architect really do?

    If you take a look on the Internet, you are able to see that the title isn't old. It was created/appeared a few years ago. I believe that it really came to the world on the end of 2005. Before that we had a lot of other Architects that we still have, such as Infrastructure Architect, Software Architect, Software Architect, Systems Architect, Enterprise Architect and others.

    I compiled some opinions about what some people think the Solutions Architect does.
    The Solutions Architect is responsible for the design or one or more applications or services within an organization, usually within the scope of a division... The Solutions Architect works with the Enterprise Architect for strategic direction (both conforming to, and helping to define).

    ...

    A 21st century title for an IT consultant or systems analyst. It implies that the person is very capable in problem solving. Like a systems analyst, a solutions architect must have a balanced mix of technical and business skills.

    ...
    There are more definitions, but what do you think? Is it only one more role/job description?
    Most places I have seen organises it something like: Solution architect is pretty much the same as software architect andd systems architect. Its the lowest pin on the ladder and the role deals with the internals and interface of one system. IT architect is the next step, and the role deals with a set of systems, the flow of data between them, shared domain models, etc. Enterprise Architects is on the top of the ladder, and the role deals with the whole system landscape, or a significant subset of it, perhaps divided after business process. Integration architect is also an entry level architect role, and it deals with integration aspects, and solutions. Infrastructure architect is also entry level, and deals with infrastructure and operational aspects of the system. There can be IT architects and Enterprise architects specialising in integration and infrastructure aspects as well.
  36. I've just accepted a new role: "Solutions Architect." I was working as Systems Architect, but I wonder: what does a Solutions Architect really do?

    If you take a look on the Internet, you are able to see that the title isn't old. It was created/appeared a few years ago. I believe that it really came to the world on the end of 2005. Before that we had a lot of other Architects that we still have, such as Infrastructure Architect, Software Architect, Software Architect, Systems Architect, Enterprise Architect and others.

    I compiled some opinions about what some people think the Solutions Architect does.
    The Solutions Architect is responsible for the design or one or more applications or services within an organization, usually within the scope of a division... The Solutions Architect works with the Enterprise Architect for strategic direction (both conforming to, and helping to define).

    ...

    A 21st century title for an IT consultant or systems analyst. It implies that the person is very capable in problem solving. Like a systems analyst, a solutions architect must have a balanced mix of technical and business skills.

    ...
    There are more definitions, but what do you think? Is it only one more role/job description?


    Most places I have seen organises it something like:

    Solution architect is pretty much the same as software architect andd systems architect. Its the lowest pin on the ladder and the role deals with the internals and interface of one system.

    IT architect is the next step, and the role deals with a set of systems, the flow of data between them, shared domain models, etc.

    Enterprise Architects is on the top of the ladder, and the role deals with the whole system landscape, or a significant subset of it, perhaps divided after business process.

    Integration architect is also an entry level architect role, and it deals with integration aspects, and solutions. Infrastructure architect is also entry level, and deals with infrastructure and operational aspects of the system. There can be IT architects and Enterprise architects specialising in integration and infrastructure aspects as well.
    Gee I get it now, It's all about buzzwords and hype (and authority). I am a debug ARCHITECT dealing exclusively with the error logging aspects of a system.
  37. good question![ Go to top ]

    In my experience they don't do much, though they are "responsible" for the overal solution and sit above the technical architect. Whether they are actually more technical is debateable. The solutions architects I've known have usually just been able to spin a good tale and have been promoted above their level of competance. When dealing with them on a technical level I have had to ask myself how the hell they managed to attain such a position. Strangely enough I posted something about this on my own blog, I'd be interested to hear your opinions on my post: http://techy.brindy.org.uk/2007/10/roles-in-software-world.html If you work out what it is you're supposed to be doing, please let us know. ;)
  38. Re: good question![ Go to top ]

    In my experience they don't do much...
    simple vitriol - what is it you're really angry about?
  39. That's easy[ Go to top ]

    The answer is to architect the solution of course. Wait, wait, wait, what was the question? :D
  40. The fact that you took a new job with a title you are not sure of is telling of how trivial the title is compared to the more important technical or domain work specific to your context. On the downside you could be fulfilling the Dilbert principal of being promoted to a position where you can do the least harm. The fact that you are focusing on the role leads me to think you work for a huge company that puts more emphasis on title and level and you are several degrees separated from accountability. Ask the person who offered you the job what problem you need to solve and then architect a solution for it. It depends on your organizational context and what hammer you bring to the table - technical, domain, or people expertise. A solutions architect will be project focused, closer to the business and thick skinned to sell a vision and motivate everyone around to buy into the vision.
  41. Solution Architects tasks[ Go to top ]

    It's regrettable that your organisation has appointed a person as solution architect who doesn't know what to do in this role. I do regret that you too had took this role . So far the received messages are not giving you the clear picture and Difference among the different architects. An enterprise architect, helps the organisation to levarage Its IT Investments to the maximum. But every organisation cannot afford to have an enterprise architect. In that case, they seek services from other companies. These companies may have Enterprise architect and provide them to the clients or take that as a project and deploy and Enterprise architect. A solution Architect is a person who provides solutions to the clients or to the same organisation.As seen on other threads, it need be bounded to a particulars company Products. The key point is, he has to visualise and analyse from all perspectives, including tomarrow's changes required to the soltuion and has to accomodate on yesterday itself. He may work along with the technical architect,Enterprise architect or provide all the solutions based on his past experience.If the roles of Solution architect and Technical architect are separately available, solution Architects job ends with providing high level design documents and not necessarily be available to supervise the production environment. On the Other hand, the Technical architect also works with SA, and he has to visualise at the components level and do the architure at a very low level. He will be working with the client on one day and be working with coding monkeys on the other day or even he may be working with a tester. TA has to be in the project even in Postproduction in some cases.Sometimes TA will be trainning the coding monkeys. ai Basically, the minimum qualifictions for all architects, I have mentioned has the below requisites (i) Visualise tomorrow's requirements on yesterday itself and accomodate in the architecture (ii) Be well ahead of developers in terms of technolgy (iii) Visualise the solution from different perspectives. Cheers.
  42. IASA[ Go to top ]

    I'm one of thoose who think that we should encourage a "common language" and not invent the defenitions over and over again. Please have a look at http://www.iasahome.org/web/home/whatwedo Cheers!
  43. Re: IASA[ Go to top ]

    I'm one of thoose who think that we should encourage a "common language" and not invent the defenitions over and over again.

    Please have a look at http://www.iasahome.org/web/home/whatwedo

    Cheers!
    That's WAY too many types of architects. It's just using "architect" to mean "senior" or "staff" or "principal" or whatever other term a company uses to distinguish a respected expert given some extra authority.
  44. Re: IASA[ Go to top ]

    Well, you may be right. Maybe you should participate in IASA to help them define the different architecture roles? :-) I don't know any other organisation who are developing and delivering standards with regards to IT-architecture. The Swedish IASA have recomended 4 different architecture roles. There is another aspect of the architecture role and that is domain. Cheers!
  45. Re: IASA[ Go to top ]

    Well, you may be right.

    Maybe you should participate in IASA to help them define the different architecture roles? :-)

    I don't know any other organisation who are developing and delivering standards with regards to IT-architecture.

    The Swedish IASA have recomended 4 different architecture roles.

    There is another aspect of the architecture role and that is domain.

    Cheers!
    Touche. I think it's a good idea to develop standard definitions, although I'm not sure anyone will follow them.
  46. Re: IASA[ Go to top ]

    Erik, I'd say that exactly the problem with the job title "Architect". Too many companies see it as a senior developer rather that a truly separate type of job. I personally am involved with IASA in the Seattle area to help define what this "Architect" thing really means, and how we can name ourselves in a way that is meaningful.
  47. Re: IASA[ Go to top ]

    help define what this "Architect" thing really means
    Designs buildings. Everyone knows that. Move on.
  48. They DO know[ Go to top ]

    Adilson, Believe me, they do know the responsibilities of every single position they offer. I mean, you accepted a role and then you came here and asked the people, and you got some answers. You might also do some research on the net and get some more answers. And then you compile what you think is closer to the organization's profile. It's as simple as that. Don't you think that your boss could do this as well? It would take him a couple of hours? Or he could ask one of his friends in another company to give him a role description. Don't you think that he should know what he pays for and what he expects from you? The answer here is that most of the times, when you are really good at what you are doing, you get promoted to some new position with some fancy title, so you are happy because the company shows you that they appreciate your work so far and get promoted. The catch: You'll continue to do 80% or 90% the tasks you were doing till now (it's simple physics, you cannot pull the breaks and stop your car in 1 msec while running at 160 Km/h) and noone will complain plus some extra 30%-40% of new responsibilities. But when something bad happens and they need to find someone to blame, then you will see how well they will get to know the exact description and responsibilities of your role. My proposal: After finishing your research, compile a list of responsibilities and targets (something like a mission statement) and present it to your boss and tell him to accept it formaly. Then concentrate mainly on this new role and aim to succeed. So, here comes the next step: What would the best for your career role description for a solution architect that you would like to present to your boss? :-)
  49. Thank you everyone for you comments. Thanks again for who wrote good descriptions about the different names. On my web site you find more information about it. I believe that I not achieved what I was expecting. My intention was to see what everybody knows about that job and try to contribute/present to who doesn't know anything about. But, the comments are taking another direction, instead of to contribute with how to be a Solutions Architect. Unfortunately, I prepared erroneously my post. I know what my job is, I didn’t accept it without know that and I’m sure that my boss and company has a very good definition what that name means. On the next time I will think about what I’m writing before to post. See you guys, Adilson Dias
  50. It's a sales job. Your job is to make the piece of c#8p you forced your junior technical architects/designers/developers to create as a System Architect under the outdated guidelines from the Enterprise Architects sound sexy, so the Stakeholders won't question all the over-the-top crazy choices and money wasted so far (or about to). Generally, this involves making people really believe that the best they can do is to keep putting square pegs in round holes. The one that spins so good he even makes himself believe it, gets to be called Enterprise Solution Architect. Best of luck,
  51. Solution Architect is a very real role[ Go to top ]

    We (as is Object Consulting) have been using the term Solution Architect since the mid 90's and see it as part of a continuum from Enterprise and Domain Architects to Solution and System Architects. It is a very central role in our methodology - Process MeNtOR. Our definition is: The Solution Architect provides technical leadership throughout the project, based on years of experience and knowledge of applicable technologies. The solution architect is responsible for producing, or coordinating the production of, the major deliverables within the Solution Engineering process unit. These include: Solution Architecture, Technology, Component and Information Architectures and the Delivery Programme. Solution Architects are only required where the problem is greater than one system development, i.e. in Enterprise situations. We have definitely noticed and increasing number of people with the title, but as with the whole industry there isn't a lot of rigour in it. Hope this helps.
  52. Scope is the issue[ Go to top ]

    It's all about the scope of your concerns: Enterprise Architect: takes into account how the various applications work together in the entire enterprise Systems Architect: more concerned with the interplay of various systems and their integration. More concerned with one silo of applications. Application Architect: concerned with the architecture of one large application. Solutions Architect: who the hell knows where this fits in.
  53. The only Solutions Architect I ever met worked for a prominent software vendor and was invited to present his companies "solution" to an IT problem. The truth is that the term "Solution Architect" probably has as many definitions as there are Solution Architects. No one opinion has more merit than any other. Trying to insert some order into this architectural chaos is The Object Group with its Architecture Framework. http://www.opengroup.org/architecture/togaf8-doc/arch/ While TOGAF defines architectural roles in an organisation, I don't recall a reference to a Solution Architect.
  54. Hi, Solution architect should be a domain experts with exposure to overall technologies. His primary responsibility is to provide the functional solutions and map it to the technology for the implementation.
  55. The answer is in this article: http://jdj.sys-con.com/read/345637.htm BTW, my title (at the company where I work) is "Senior Architect" :)
  56. We have some solution architects where I work. What seems to be happening over time (about 2 years now) is that the solution architects are losing their skillsets and their overall technical mojo through lack of use. So in the beginning (2005 or so) the S.A.s would have decent solutions that could be made to work. But as of late 2007, I'd have to say the S.A. derived solutions have subtracted rather than added value to projects. The reason being, the solution architects just haven't been able to keep up with what's going on with the enterprise technology stack (we have over 100,000 employees) and the technology world as well as the *technical* architects and developers. The solution architects realize this and aren't happy about it. They're often in meetings for 50-80% of the day, so it's almost impossible for them to keep their skills up. What has happened (again, where I work) is that the solution architects have become more decoupled from the technology realm, and are spending more time in meetings with business groups. The S.A.s produce some Microsoft Word docs on solutions when they can. These are handed off to the Technical Architects, who (de facto) read them once and take them "under advisement" as they say. In other words, "we'll give it a try." I'd say the Word docs from the solution architects do flavor the first rounds of thinking about a project by the technical architect and the developers. The saving grace has been that the technical architects have been quite happy to share the burden of doing the coding, so in reality we've seen the technical architect and a lead developer or two white board a project, and then start coding. I guess this is a long-winded way of saying, it may be challenging if you're in the role of solution architect to stay relevant after a couple of years. You may need to fight to find ways to keep your skills updated and sharp. But I guess that's why they call it "work" and not "play" :)
  57. My reply--[ Go to top ]

    Here I have copy & paste one requirement from the job posting.. - Master/Degree in Computer Science, Information technology, Computer Engineering or related disciplines. - 7- 10 years of working experience in Java development, particularly core Java including threads and sockets programming. - Strong proven track record as a Solution Architect in large and complex projects. - Must have extensive knowledge and experience in J2SE / J2EE development skills (JSP, JMS, JDBC, Struts). - Strong skills in XML (SXLT, XPath and DTDs), SQL. - A broad understanding of UML and reusable design is mandatory - Experience with relational databases, particularly ASE, Oracle, SQL Server - Experience in C/C++ preferred. - Good knowledge in Linux environment and queuing technologies (Perl and Shell). - Knowledge in telecommunication wireless data/messaging technologies (SMS, MMS, SMPP, HTTP and etc) an advantage. - Strong technical leadership, analytical with good communications and interpersonal skills. - Willing and comfortable to do hands-on development work.