none
Can an Architect be technology agnostic? RRS feed

  • Question

  • Hi,

    Today's enterprises are flooded with a mix of technologies.  It is no more one stop shop technology.  I see this more and more in the companies I have worked with.  .NET and JEE are predominatly used, but I also see flair or Ruby cropping up.

     

    So the question is, an Architect be technology agnostic.  Especially around .NET and JEE, you can do almost everything in one or other, except cross platform deficiency on .NET (Mono can fill the gap) and Rich user experience for desktop apps deficiency on JEE.

     

    Yes, you have to look at cultural bias, current technology stack investment, familiarity all goes in place when you choose a technology.

     

    Especially cultural bias is the hard one to crack because people tend to hate one technology over other and refuse to use even if there is better benefit.  Sometimes, I feel people work for IBM, MS or Oracle instead of working for like myManufacturer or myPharma.

     

    But how much the above carry the weight when you want to architect a solution that fits be problem statement Vs current investment and cultural bias.

     

    When you pick a technology stack for the problem statement, do you already say, this is going to be built on technology X, so I will only explore options in that?  I say BIG NO.  What do you guys think.

    Thursday, May 22, 2008 3:30 PM

Answers

  • I think you could be agnostic of technology if you wanted to be a theoretical architect.  Sit in the ivory tower and tell people how it should be done.

     

    That said, my view is that an architect should design with a technology in mind, but not in a way that leads the architecture to a technology bias.  All your eggs in one basket is a bad approach, in my opinion.  Sometimes it is necessary, but that ties the solution to a particular path.  If performance is key, then the compromise would be just that, otherwise as far as is possible, I would architect a solution that could be implemented in a number of languages, with a wide range of technologies.

     

    I don't really take the point that 'people' hate a technology so the architect should use the technology that the masses like.  That's really down to the skills of the architect to convince people that a particular direction is the correct one.

    That said, there is something to be said for going for a language where the knowledge is, but that should be down to the consts of training, resources and so on, rather than "what people like" (or hate).

     

    I don't think that an architecture shoudl ever start at a technology.  Consider that a user in one company wants to send a textual message to a user in another company.  If we decided on the technology first, say MSMQ, then realised that there was a better way, use e-mail, we would have the completely wrong solution.  However, if we analysed the problem space first, came up with a conceptual architecture, we'd quickly realise the situation with e-mail, and nothign would be lost.  In reality, anyone who doesn't realise that shouldn't be an architect.

     

    The other difficulty, and this seems to happen often, is that people pick 'cool' technology, then contrive a solution around it, they are not architects.  The 'cool' technology is probably an anti-pattern is the making since it was chosen for its coolness rather than the correct fit for the requirements of the system.

     

    Martin Platt.

     

    Friday, May 30, 2008 4:46 AM
  •  

    One of the requirement for Architect is that he/she needs to have knowledge of multiple technologies. But on the other hand we do have a role called "Technical Architect" where one needs to be competetent in one technology. Say DotNet Architect, J2EE architect.etc. There are several roles floating in market today with these or similar titles.

     

    But one of the constraints we face is of technology. I remember once I was asked to work for a government department here in Australia and we had techonology constraints like Weblogic 6.1 with EJB 2.0 and Oracle. So whatever solution is being proposed has to consider these factors as the department had invested huge sum in these technologies. Ideally we should be saying NO in these circumstances but then we are not living in ideal world.

     

    Cheers

    Samir Kumar Mishra

    Tuesday, June 3, 2008 12:38 AM
  • I agree, I think it's a question of pragmatism. Ideally an arch' understands every platform and will be able to say what platform and technology to use. However, real life is a bit different. In a number of cases the platform & base technologies will be a given with no room to change and the company will employee an arch' with experience in that platform. So you're unlikely (not impossible) to get a job arch' a .net platform if you've only got Oracle & J2EE experience. Looking from another angle is you only know what you know! If you've been lucky (or determined) enough to use different platforms that you'll have that experience and you're a step closer to the ideal and can take all sorts of jobs. However, if you've only worked on one platform then you may get pigeon holed as the...Unix arch' (or whatever) and only get the opportunity to gain more experience in the same field. Obviously the more abstract notions of arch' will be platform agnostic (e.g. using a queue, ESB, etc) but I'm not sure if being a master of the abstract notions without the target platform experience would realistically get you the job.

     

    Friday, June 6, 2008 10:48 AM
  • pkr, I think you hit the nail on this pretty good. 

     

    I agree with you that an arch. needs a good amount of horizontal depth, but need strong vertical depth on one platform...  I have been lucky to have opportunities that challenge me to look mostly in JEE stack and sparingly on .NET stack.

    The reason I probed this question is that since we are a huge JEE shop, we dont look at .NET unless it is an old VB platform that we are looking to migrate or vended solution that is built on .NET.

    Friday, June 6, 2008 6:27 PM
  • Guys,

       coming back to the original question (I read the whole thread and seems that the main point led to a particular discussion on Java and .NET communities, which one is right, etc)

     

       Let's start by declaring that being agnostic does not imply being ignorant. As far as I understand, an architect techologically agnostic is the one willing to incorporate new technologies in detriment of older one currently being used if those will better support the business in the mid/long term

     

       If that later premise is valid, it shouldn't be just possible for an architect being technologically agnostic but also desirable

     

       Of course, the question here, when I say "agnostic must not imply ignorant" is "how much should he/she know about the set of technologies". Despite I don't have a ruler to measure how much, I dare to say that a general awareness on the most important alternatives (easy to validate with a PoC) should be enough

     

       When I was faced to the need of incorporating a solution ready to use, I remember that in my first ages as an architect I wanted to know/test ALL the available alternatives but later experience showed me that narrowing the list of candidates to a reduced set (usually 5 plus/minus 2) could be good

     

       The more heterogeneous the set, the better (by heterogeneous I mean, including big vendors solution but open source candidates as well, hybrid approaches, etc)

     

     

     

    Just my 5 cts

    Wednesday, June 18, 2008 1:32 AM
  •  LudovicoVan wrote:
    > There are components, models, generators, and engines in the software industry today. Do you still think that having and using components, models, generators, and engines is impossible?

     

    What is impossible is the last step: getting from there to the room with one big red button to push, otherwise "pure model driven" as you might like to call it.


    There is already components, models, generators, and engines today, so there is no last step that has not been done. Every step has been done. Of course pure model driven approach is in many cases too heavy, but that doesn' t mean that model driven development cannot happen. There are success stories that have cut development time significantly where thanks goes to MDD.


     LudovicoVan wrote:
    With an analogy, the situation is not different than when you rush up on a project and find yourself in troubles on the last 10-20%: the more you have been quick, the more you are stack.


    The situation is different and the means are different. For example if we want to build a business system, we only need some engine and input all business rules and models there and there we have it. But if we want to do complex programming with C, then we have to go back to traditional methods unless we have some huge project that has resources to develop helping tools besides the traditional methods.


     LudovicoVan wrote:
    And then you can glimpse that there is no enigma behind software project failures, just a hugh massive flooding amount of incompetence and ignorance of even the most basic principles and elementar facts that make up this discipline. - -

     

    Software projects can be and have been improved with MDD.

    Monday, July 7, 2008 7:37 PM
  • Yes there is. Of course its not quite that simple to use, but the basic principles goes like that. Even I can build one.

    Lets take a database. Create tables for business rules. Then create software that executes those rules. Input the rules, and its done. This was my 20 second plan. Others have used hundreds of thousands of hours building such things, and they are quite advanced.
    Monday, July 7, 2008 8:32 PM
  •  LudovicoVan wrote:

     Silvercode wrote:
     For example if we want to build a business system, we only need some engine and input all business rules and models there and there we have it.

    You keep dreaming, of an improductive dream. There is no such thing yet, and in such terms there will never be.

     

    I have to agree with Silvercode on this.  What Silvercode has mentioned in the above is the highly matured BPM solution.  I did not have a luck in working on one of the matured state BPM solution yet, but do have friends/practioners that has first-hand experience of implementing and supporting those solutions.  In those shops IT/Technology is an enabler of business strategy.  It is not a dream.  Hoping that will never happen is an improductive dream Smile

    Monday, July 7, 2008 9:19 PM

All replies

  • How can an Architect be agnostic to technology when his/her primary role is indeed managing the technological infrastructure?

     

    I usually suggest a good book on Software Engineering for a broader picture on the SDLC and the roles involved. Pressman's is the one I prefer.

     

    Hope it helps.

     

    -LV

    Friday, May 23, 2008 4:46 AM
  • If you are an architect that knows only JEE, architecting a solution for desktop application would be a disaster dont you think?

    I agree that every one has a bias for one technology Vs other, but if you dont know what is on the other asile and trends outside the current comfort zone, dont you become obsolete?

    How much should an architect's bias drive a square peg in a round hole?
    Friday, May 23, 2008 2:06 PM
  •  GajaKannan wrote:

    If you are an architect that knows only JEE, architecting a solution for desktop application would be a disaster dont you think?

     

    Well, no, I don't think so.

     

    Mainly because if you only know JEE, I don't see how you can be an Architect anyway. That is, I believe in the thesis that an Architect must have a very solid and broad technical background, and if s/he is not even able to move confortably from -say- web development to desktop development and back, then what kind of Architect is this?

     

    I think here we converge with a comment just made by pkr2000 in the thread "Call yourself an Architect?" which I'll partially quote here:

     

    >> "given an architect should be platform agnostic should they be able to code in any platform?"

     

    I think the way pkr2000 is putting it is still a bit paradoxical, but maybe it's that I do not really "get into the role".

     

    In any case, food for thought... and proper discussion.

     

    -LV

    Friday, May 23, 2008 4:07 PM
  •  LudovicoVan wrote:

    How can an Architect be agnostic to technology when his/her primary role is indeed managing the technological infrastructure?

     

    hmmmm...  I am confused...  My response was to your comment above that "how can an architect be agnostic to technology"  Sounds like you are switching position in your second response that "architect should be agnostic to technology"  Where do you stand LudovicoVan.  Agnostic or married to one platform?

    Friday, May 23, 2008 7:36 PM
  •  GajaKannan wrote:
    Where do you stand LudovicoVan.  Agnostic or married to one platform?

     

    Neither! They are BOTH WRONG.

     

    As I have said many times now in this forum, I do not agree with the way you guys tend to put it, and find a point of contact only by taking your positions to their paradoxical extremes, where two wrongs get *similar* to a right, although not quite it.

     

    You just keep forgetting the key ingredient: first a PROBLEM SOLVER, and then the kind of problems involved, and then the approaches to solve them, etc. etc.

     

    But you guys are too busy with your shopping lists, so busy that you even make lists of problems with their solutions... Cool, but it's not Architecture and not even any form of Engineering: it's called Buying (cheap, you hope) and Selling (expensive, you try).

     

    Yours is the never science of selling your science. Best luck with it, but I am not interested.

     

    -LV

     

    P.S. Sorry, for days I have not been able to login to this forum. Anyway this is going to be my last message around here. Technicians vs. Sellers: just a big waste of time and money for the Customers, and a lot of pain for the Users. I couldn't care less for such jokes.

    Thursday, May 29, 2008 7:55 PM
  • I think you could be agnostic of technology if you wanted to be a theoretical architect.  Sit in the ivory tower and tell people how it should be done.

     

    That said, my view is that an architect should design with a technology in mind, but not in a way that leads the architecture to a technology bias.  All your eggs in one basket is a bad approach, in my opinion.  Sometimes it is necessary, but that ties the solution to a particular path.  If performance is key, then the compromise would be just that, otherwise as far as is possible, I would architect a solution that could be implemented in a number of languages, with a wide range of technologies.

     

    I don't really take the point that 'people' hate a technology so the architect should use the technology that the masses like.  That's really down to the skills of the architect to convince people that a particular direction is the correct one.

    That said, there is something to be said for going for a language where the knowledge is, but that should be down to the consts of training, resources and so on, rather than "what people like" (or hate).

     

    I don't think that an architecture shoudl ever start at a technology.  Consider that a user in one company wants to send a textual message to a user in another company.  If we decided on the technology first, say MSMQ, then realised that there was a better way, use e-mail, we would have the completely wrong solution.  However, if we analysed the problem space first, came up with a conceptual architecture, we'd quickly realise the situation with e-mail, and nothign would be lost.  In reality, anyone who doesn't realise that shouldn't be an architect.

     

    The other difficulty, and this seems to happen often, is that people pick 'cool' technology, then contrive a solution around it, they are not architects.  The 'cool' technology is probably an anti-pattern is the making since it was chosen for its coolness rather than the correct fit for the requirements of the system.

     

    Martin Platt.

     

    Friday, May 30, 2008 4:46 AM
  •  

    One of the requirement for Architect is that he/she needs to have knowledge of multiple technologies. But on the other hand we do have a role called "Technical Architect" where one needs to be competetent in one technology. Say DotNet Architect, J2EE architect.etc. There are several roles floating in market today with these or similar titles.

     

    But one of the constraints we face is of technology. I remember once I was asked to work for a government department here in Australia and we had techonology constraints like Weblogic 6.1 with EJB 2.0 and Oracle. So whatever solution is being proposed has to consider these factors as the department had invested huge sum in these technologies. Ideally we should be saying NO in these circumstances but then we are not living in ideal world.

     

    Cheers

    Samir Kumar Mishra

    Tuesday, June 3, 2008 12:38 AM
  • I agree, I think it's a question of pragmatism. Ideally an arch' understands every platform and will be able to say what platform and technology to use. However, real life is a bit different. In a number of cases the platform & base technologies will be a given with no room to change and the company will employee an arch' with experience in that platform. So you're unlikely (not impossible) to get a job arch' a .net platform if you've only got Oracle & J2EE experience. Looking from another angle is you only know what you know! If you've been lucky (or determined) enough to use different platforms that you'll have that experience and you're a step closer to the ideal and can take all sorts of jobs. However, if you've only worked on one platform then you may get pigeon holed as the...Unix arch' (or whatever) and only get the opportunity to gain more experience in the same field. Obviously the more abstract notions of arch' will be platform agnostic (e.g. using a queue, ESB, etc) but I'm not sure if being a master of the abstract notions without the target platform experience would realistically get you the job.

     

    Friday, June 6, 2008 10:48 AM
  • pkr, I think you hit the nail on this pretty good. 

     

    I agree with you that an arch. needs a good amount of horizontal depth, but need strong vertical depth on one platform...  I have been lucky to have opportunities that challenge me to look mostly in JEE stack and sparingly on .NET stack.

    The reason I probed this question is that since we are a huge JEE shop, we dont look at .NET unless it is an old VB platform that we are looking to migrate or vended solution that is built on .NET.

    Friday, June 6, 2008 6:27 PM
  • Honestly, if there is one thing I would abolish and make outlaw, as well as making it a criterion for *not* certifying people in software architecture nor in any other software related discipline for the sake, then that is Java, Java technologies, and the Java community with all the misknowledge and the misconceptions that have made a mess of software development in something like a bare ten years.

     

    So, thanks a million to the Java community and to all the related super-famous experts that have made our life so more interesting and challenging since then. We had software engineering, with communication and collaboration, modularity and interoperability; now we have the independence mismatch and OO/DDD/BLL uber alles. Even better: now people [Architects!! and even PMs!!! Analysts? Never...] go do business analysis with use cases and class diagrams!

     

    Long live the Java community: just stay out of my way.

     

    -LV

    Friday, June 6, 2008 8:46 PM
  •  pkr2000 wrote:
    So you're unlikely (not impossible) to get a job arch' a .net platform if you've only got Oracle & J2EE experience.

     

    On a first instance, I agree with you on this, although I will add that it is our own responsibility to broaden our professional perspective, because, given how things are going in the industry as well as the marketplaces, the pace of the companies who employ us is so slow that, should you ever be so crazy to follow them, you are going to be professionally dead in 12 months or so.

     

    Moreover, I'll tell you this: if one knows only J2EE over Oracle, what architect can that be at all?!! In other words, I believe you need some 10 years only to start getting what software production is about (there is more to programming then just programming and so on... = 10 years just to get "what"). Then you need another 10 years to learn what there is to learn, and become what you like, including becoming an Architect... although, at that point, Architecture will be apparently an empty slogan for you, as it just is.

     

     pkr2000 wrote:
    Looking from another angle is you only know what you know! If you've been lucky (or determined) enough to use different platforms that you'll have that experience and you're a step closer to the ideal and can take all sorts of jobs. However, if you've only worked on one platform then you may get pigeon holed as the...Unix arch' (or whatever) and only get the opportunity to gain more experience in the same field. Obviously the more abstract notions of arch' will be platform agnostic (e.g. using a queue, ESB, etc) but I'm not sure if being a master of the abstract notions without the target platform experience would realistically get you the job.

     

    Whatever we do, Architect or not, our domain is so complex and abstract that it requires us to be GENERAL PURPOSE, MULTIVERSATILE, KILLER LEVEL, PROBLEM SOLVER: first of all, ever! If we have that (that is, some 15 years building real systems, and failing, and recovering, then succeding, then failing again, and the kind of life we live and don't live, and our world, and so on), we have all that is needed. But, if we haven't got *that*, then let's just peek our degree (computer science is a guarantee of joy) and let's go work for some media agency, or let's even open our own business and let's build web applications: the whole market is there with us!

     

    -LV

    Friday, June 6, 2008 9:26 PM
  •  LudovicoVan wrote:

    Honestly, if there is one thing I would abolish and make outlaw, as well as making it a criterion for *not* certifying people in software architecture nor in any other software related discipline for the sake, then that is Java, Java technologies, and the Java community with all the misknowledge and the misconceptions that have made a mess of software development in something like a bare ten years.

     

    So, thanks a million to the Java community and to all the related super-famous experts that have made our life so more interesting and challenging since then. We had software engineering, with communication and collaboration, modularity and interoperability; now we have the independence mismatch and OO/DDD/BLL uber alles. Even better: now people [Architects!! and even PMs!!! Analysts? Never...] go do business analysis with use cases and class diagrams!

     

    Long live the Java community: just stay out of my way.

     

    -LV

    LOL

    I dont think Java or java community is that bad like you described above.  You sound like some of my peers that have similar opinion about MS and .NET technology even though they probably have not spent more than one day exposure in .NET...

    Saturday, June 7, 2008 4:19 AM
  • GajaKannan:

     

    > I dont think Java or java community is that bad like you described above.

     

    You can think whatever you like. The difference is in that I give technical reasons and explanations, while you only give LOLs.

     

    > You sound like some of my peers that have similar opinion about MS and .NET technology even though they probably have not spent more than one day exposure in .NET...

     

    That's your problem. I have been working with both and know what I am talking about. Again, you and your collegues have your LOLs.

     

    -LV

    Saturday, June 7, 2008 8:20 PM
  •  GajaKannan wrote:

    LOL

    I dont think Java or java community is that bad like you described above.  You sound like some of my peers that have similar opinion about MS and .NET technology even though they probably have not spent more than one day exposure in .NET...

     

    Yeah it's in some peoples nature to want to team up around something and the defend it without reason, just look at the Mac (or should I say iPod) users...donning flame proof jacket (I am one so don't start!). But as this post talks about you really want to be a little more...constructive and have the experience to back it up. Having said that such zealots could make good arch' in their chosen field just not so good for green field or interop' developments - so perhaps there isn't much room for them at all?

     

     

     

    Monday, June 9, 2008 7:02 AM
  • Okay LV, here is my expansion for LOLs and why Java community is not bad.  They have contributed a lot that MS has adopted in their suite of products.  I am listing only a short list of development tools below as we are comparing .NET and Java not Windows/Linux.  That would be a separate thread Smile

     

    There is a whole lot of examples I can provide.  Here are few...

     

    Log4J - EntLib - Log4net

    Ant (Java) - NAnt (.NET Open Source) - MSBuild (Microsoft)

    xUnit - NUnit (and other .NET unit testing flavours)

    Spring Framework - SpringFramework.NET (Container, IOC)

    Mock - NMock (Other Mock frameworks)

    Hibernate - NHibernate - (Awesome ORM frameworks)

    Eclipse - Express editions of VS

    Eclipse mylyn - VS Team System work item based development

    SOA (Although overused and overhyped terminology, the hype was created by Java community before MS got onboard)

    Portal (Sharepoint is catching up and filling the lead by Java Tools)

     

    All the above mentioned and many more was borrowed and Java community and made at par, or better, or worse in .NET by community or MS.

     

    Just as I mentioned earlier, I do use both the technologies and use them for their strengths, how they fit the problem statement and cultural affinity.  I designed, developed and deployed the first internet facing https webservice for the company(Fortune 500) that I work for in Java and designed, developed and deployed the first .NET based SOA application in my line of business for the same company.

     

    I would not blindly follow a technology or a vendor.

    Monday, June 9, 2008 3:12 PM
  • GajaKannan:

     

    > Okay LV, here is my expansion for LOLs and why Java community is not bad.

     

    Thanks, I appreciate that and can see your point. Indeed, that is not nothing! as I would put it...

     

    > I would not blindly follow a technology or a vendor.

     

    Me neither, and never have anyway, although there are technologies (and even methodologies) that I prefer or have preferred over others at a certain point in time.

     

    When I blame "the Java community" I am talking about -- literally, although IMHO -- the mess they have made of software development metodologies and practices. Then they have supported it with mirabolant tools and frameworks. In a word in 10 years they have blown up all key notions of Information and Software Engineering, that is what had been acquired in bare 30 years, still a branch of Engineering, itself a discipline with a solid history.

     

    When I say "the Java community" is also because there is no point in trying to tell or not tell who or not who. It's just happend within and around the Java community, because of the very structure (conception) of the Java language and the Java framework, and has grown fast because it appealed the new generation, that is when the Web had just started and the whole IT industry was flooded.

     

    It even partly works... I mean, Java, with a bit of care and experience, and some struggles sometimes. Some key limits are inescapable. The .Net platform, for instance, does not suffer of any such limitations. Then you can have NHibernate in .Net, then I can find it in the companies I work for, along with BLL and OO uber alles, then I get pissed off. Wink

     

    -LV

    Monday, June 9, 2008 10:52 PM
  • > Then you can have NHibernate in .Net, then I can find it in the companies I work for, along with BLL and OO uber alles, then I get pissed off.

     

    To the real drama: imagine you, first day on a new job, senior of some sort, trying to tell a guy with 2-3 years experience why BLL and OO uber alles is not that good, and O/RM is mostly a misconception and a side effect of the two former... Then try and tell him where analysis is gone. Who's seen it recently? The first day on a new job, senior or not senior, one is supposed to be nice. That's why I am not nice...

     

    [P.S. Sorry, forgot to mention that usually that guy has been there since day one or so...]

     

    -LV

    Monday, June 9, 2008 11:13 PM
  • Guys,

       coming back to the original question (I read the whole thread and seems that the main point led to a particular discussion on Java and .NET communities, which one is right, etc)

     

       Let's start by declaring that being agnostic does not imply being ignorant. As far as I understand, an architect techologically agnostic is the one willing to incorporate new technologies in detriment of older one currently being used if those will better support the business in the mid/long term

     

       If that later premise is valid, it shouldn't be just possible for an architect being technologically agnostic but also desirable

     

       Of course, the question here, when I say "agnostic must not imply ignorant" is "how much should he/she know about the set of technologies". Despite I don't have a ruler to measure how much, I dare to say that a general awareness on the most important alternatives (easy to validate with a PoC) should be enough

     

       When I was faced to the need of incorporating a solution ready to use, I remember that in my first ages as an architect I wanted to know/test ALL the available alternatives but later experience showed me that narrowing the list of candidates to a reduced set (usually 5 plus/minus 2) could be good

     

       The more heterogeneous the set, the better (by heterogeneous I mean, including big vendors solution but open source candidates as well, hybrid approaches, etc)

     

     

     

    Just my 5 cts

    Wednesday, June 18, 2008 1:32 AM
  •  

    Technology choices are usually always contingent upon cost, impact on internal resources and time to implement. Sales, marketing, advertising and development partners all have great influence on software purchases. IMHO the biggest asset that Microsoft owns today is not its technology but its sales, marketing and support network.

     

    I find it funny that a vast majority of developers squabble over programming languages and platform preferences as opposed to understanding their business domain. Don’t get me wrong, it’s very important to challenge software design the same way a doctor has to defend his treatment choices when facing a panel. But discounting a technology purely for personal reasons is immature.

     

    Cheers!

    Wednesday, June 18, 2008 10:01 PM
  •  Diego Dagum wrote:

    Guys,

       coming back to the original question (I read the whole thread and seems that the main point led to a particular discussion on Java and .NET communities, which one is right, etc)

     

       Let's start by declaring that being agnostic does not imply being ignorant. As far as I understand, an architect techologically agnostic is the one willing to incorporate new technologies in detriment of older one currently being used if those will better support the business in the mid/long term

     

       If that later premise is valid, it shouldn't be just possible for an architect being technologically agnostic but also desirable

     

    Honestly, you just confirm that no serious discussion is possible in this forum.

     

    Indeed, nothing new under the sun.

     

    -LV

    Wednesday, June 18, 2008 10:13 PM
  •  

    I think, Architect must be jack of all technologies and master of any one. E.g. He should have the full knowledge of any Client / Server techonology.

     

    Wednesday, June 25, 2008 3:35 PM
  •  Pankaj Naval wrote:

     

    I think, Architect must be jack of all technologies and master of any one. E.g. He should have the full knowledge of any Client / Server techonology.

     



    As an ideal I'd agree, but then who wouldn't want to be a master of everything they do! However, realistically it's not practical.

    Thursday, June 26, 2008 5:49 AM
  • why not?

     

    I have deep knowledge in .NET technologies, but I know JEE and have written enterprise grade apps in JEE.  I understand and wrote sample learning programs in RoR, Python, PHP, etc.,

     

    Well, did I mention I spend more time on computer than anything else about 12 hours a day and 4+ hours on a weekend...

     

    Thursday, June 26, 2008 4:52 PM
  • even with your soul melting time I think *any* is a tall order...even for you Wink. I'm sure being omnipotent would be boring anyway.


    Thursday, June 26, 2008 9:09 PM
  • Is any possible for anyone...  I should have been clear...  In my mind, i was thinking about enterprise techstacks Smile

     

    Thursday, June 26, 2008 10:50 PM
  • I dont even want to claim to have as much experience as you guys but in the experience I do have I have to agree with Raman,  I have rarely worked anywhere that did not already have an established domain and a tight budget and unreasonable timeline.  Very rare indeed that the Domain could be designed and platforms/technologies selected.  Usually its adding a piece to the jigsaw as fast and as cheap as possible, and 90% of the time that seems to be the only consideration, an acceptable solution, cheap as possible, using existing resources and skills.

    Perhaps I am at the wrong end of the market Smile

    As for being technology agnostic, it depends on your scope, if you work for a company with an established domain, you most likely have to work in the technology that exists, be that .Net or any other, the more time you spend there the more you will become that technology.

    If you contract or consult for different companies then you would most certainly benefit from being technology agnostic, but it's not absolutley required, as if you are vertically proficent in only .Net technologies then you will pick up/find .Net contracts or provide .Net solutions to anything that is an open slate.


    Saturday, June 28, 2008 8:35 AM
  • GavH, whilst I do agree with a lot of what you said, however if you only appreciate .net then you may constrain the arch' by making it difficult to interop with other systems. But like I say I think practically they'll be more examples of your experience than not.

    Sunday, June 29, 2008 9:56 AM
  • Architects should not program in any platform. They have programmers for that.

    If platforms like .NET and JEE are so hard to grasp and comprehend that the architect needs years of experience of each of the platforms, then the world has an error. The platforms should offer low entry costs so that the architect doesn't have to wade in endless swamps of configuration files etc. other mysterious stuff before being able to do some architecting on the platform.

    Lets take the skyscrapers again. A building is a building. There are no .NET buildings and JEE buildings. They just build the buildings. Surely there are wooden cottages and steel skyscrapers, but that is like selecting between architecting a small desktop software or a big corporate system.

    Even better: The learning curve should come from the science of engineering software systems, not from 3rd party platforms. If an architect has the education of System Architect or Software Architect, that should be enough for any platform of the chosen field. It is the job of the platforms to support the architect, not the other way around.
    Wednesday, July 2, 2008 9:47 AM
  • Whilst I appreciate that in theory there should be no need for an arch' to get their hands dirty, practically I think they need to have a good understanding of the technology used. As has been covered extensively before, that doens't mean they have to carry out development tasks, "just" that they should have some experience. If you read the interviews on skyscrapper site then most (if not all) of the top arch's interviewed all take time to try the technologies themsleves.

     

    Wednesday, July 2, 2008 10:03 AM
  • For example what technologies a skyscraper architect tries out? New fancy wet concrete spewing machines? Steel cutting diamond blades?

    I think that there should be more separation in levels of doing. I have suggested that there is the architect, main designers, and normal designers, and the programmers. And then comes the project managers and business analysts.

    Of course there still can be small companies too in the future, but for the industry to get going, we need to consider the bigger picture. Its not nice to see that its quite common that people are creating systems by hand crafting mostly and even without good separation between designers and programmers.

    The architect doesn't do what the main designer does. The main designer doesn't do what a normal designer does. Those don't do what a programmer does. So from an architect to a programmer there is already a wide gap.

    Architect -> Architecture
    Main designer -> Designs of common widgets
    Business analyst -> Business model and requirements of the system
    Normal designer -> Design of the system
    Programmer -> The actual software code

    Lets also add the separation of system and software architecting:

    System architect -> System architecture
    System main designer -> Designs of common system widgets
    Business analyst -> Business model and requirements of the system
    System normal designer -> Design of the system
    System developer -> The actual system implementation
    Tester -> System testing

    Software architect -> Software architecture
    Software main designer -> Designs of common software widgets
    Business analyst -> Business model and requirements of the software
    Software normal designer -> Design of the software
    Programmer -> The actual software code
    Tester -> Software testing

    Now I don't think that an architect does much of programming. Of course its good to know about technical stuff and try them out, but I think that separation of levels is not happening in many software companies. Its more like there is one Lead Developer who installs dotNet framework and Visual Studio and database and creates the initial frameworks, and after that more developers are added to the soup while the lead developer starts to call himself the architect. After that the lead developer is soon promoted to a project manager and then the project ceases into a desperate supporting phase.

    Yes, we can add also Database Admin or such to the levels.

    Why a software designer should take care about how a common custom widget is created? Its the job of a software main designer. Then a programmer creates the software according to the software designs using the widget and the software architecture. The architect doesn't even design common widgets nor program them.
    Wednesday, July 2, 2008 11:53 AM
  • I abs. agree with the different roles and I don't think we're disagreeing on that point. The core point is they should have some experience in order to appreciate some of the contraints, as I've said ideally that wouldn't be the case but practically it is so. Also as far as building arch' well when the train they most certainly do have a hands-on experience with the materials, and they reasearch them thoroughly, at least the guys I went to college with did. In fact I can probably talk for some length on the properties of Pilkerton Curtain Walling Wink

     

     

     

    Wednesday, July 2, 2008 1:03 PM
  • Alright, a building architect decides his building will get glass walls for modern open looks. He does some research and finds out there indeed exists technology for glass walls and one vendor for them is Pilkington. No problem, a good architect always checks things beforehand and off he goes creating an architecture that has glass walls.

    Pilkington Curtain Walls
    http://www.pilkington.com/applications/products2006/english/byapplication/commercial/curtainwall/default.htm

    Those walls are like a widget that a building architect knows about. Its like a software programmer drags a glassy label widget into the graphical user interface of an application window. Is the building architect just been reduced to a mere builder? No.

    In order to use a glassy label widget a software architect has done some research and found out there exists glassy label widgets. Alright, he adds them to the architecture portfolio of widgets that are available for usage. Did the software architect just do some programming? No. Designing? No.

    Why would a software architect add the glassy label widget to the architecture? Because the Usability Person wanted to have glassy labels in the style of the software. If that glassy label widget didn't exist, then the usability person would have had to order the widget from the main designer. The main designer would have asked the architect is it ok to add such a widget. The architect would have said "sure" knowing that a simple new widget is not going to do any harm and then the main designer designed the widget according to the software architecture. After that a programmer would have programmed the widget.
    Wednesday, July 2, 2008 1:53 PM
  • I don't want to drag the build example out, but no they did learn how to fit it, the needed to know about all the physical properties of it. So when a client comes to them and says I need a glassy wall the Arch' can say fine but it needs to support x, meet fire regulation y, cost z to be fitted, etc, etc. So from our rather nasty building analogy the BA comes to the software arch' and says I need the input from A to be queued then the arch' should, IMO, be able to choose the best queuing technology available to meet all the varied needs of the project. To do that it's better that they've had experience of using that queueing technology-  required no - better yes. The opposite of that would be to say that it's better for them to have no experience in the technology and just pass on the requirement of a queuing technology to the software designer. Ok, that can work, but IMO part the arch' role is to make those technology decisions, not in a thou shall use my recommendations, but certainly to present a set of suggested techologies. I agree it's potentially a blurring of roles but I think that's probably realistic too. A software designer will have good views on arch', as would a tester. I don't think you can simply ring fence peoples skills. So again, to be clear I don't believe a Arch' should be developing the software, (at least not in that role), but it is an advantage to make decisions based upon experience than not. Not a pre-req, just better.

     

     

     

    Wednesday, July 2, 2008 2:55 PM
  •  Silvercode wrote:
    Architects should not program in any platform. They have programmers for that.

    I agree, programming is not architects job.  It is programmer's job.  Just like pkr mentioned, if you dont get your feet wet and understand the platform, how can you architect a solution in that platform.  I could not architect a solution in JEE until I got my feet wet and understood the platform.  Now I am very comfortable in architecting solutions in JEE because I have that connection with that platform.  Just like I mentioned earlier, I understand Ruby, Perl,Python, but would not architect a solution using those technologies because I dont know the implications of my technical decisions.  Either programmers have to shove it in their throat or a solution that is not robust enough...


     Silvercode wrote:

    If platforms like .NET and JEE are so hard to grasp and comprehend that the architect needs years of experience of each of the platforms, then the world has an error. The platforms should offer low entry costs so that the architect doesn't have to wade in endless swamps of configuration files etc. other mysterious stuff before being able to do some architecting on the platform.

     

    I agree, the entry costs of JEE platform is very high, and .NET is starting to increase the learning curve.  Although not a scientific fact to support, my observation is that, complex the platform, it has higher respect in the industry.  There is still a dogma for MS technologies being only a pretty user interface platform and less of enterprise grade, compared to JEE even though has terrible user interface richness, but celebrated in the industry just for being enterprise grade, in this case enterprise grade is more complex.  There are enterprise architects that told me that they would not use Ruby on Rails because it is suited only for small scale applications and not ready for enterprise grade till rich frameworks evolve.

     

     

    Wednesday, July 2, 2008 2:58 PM
  • Yes the roles blur somewhat, but that is why there has to be dictating power for some people over others. Otherwise there is a danger that the roles blur too much. There can be discussions, but someone has to have the final word.

    If you create dotNet applications, then there is pretty much obvious solution to select MSMQ. But like I said, the platforms (.NET, JEE) should support the role of the architect, not vice versa.

    For example we all know what a wall is. A wall is something that you cannot go through and the wall has some properties like thickness and robustness and so on. But its a wall. So the architect will know that he wants a wall that is about 10 to 30 cm thick. Alright, then its the responsibility of wall makers to produce walls that are 10 to 30 cm thick that suites the purpose of the architect.

    I mean, its not so that the architect goes to different wall shops and starts studying the walls. WallShopX has wall, that has pointy sticks in it. The architect thinks "what ... I don't want pointy sticks in my wall" and goes to WallShopY.
    WallShopY has walls that have pictures of jungle on it. The architect thinks "what ... I don't want jungle pictures on my wall." You see? We all know what a wall is and the wall vendors should create walls according to our needs.

    If the wall needs to support x, for example steel grids, so what? Would any wall vendor sell wall that doesn't support it, because the wall would be useless? No one wants to sell useless stuff.

    Now the queueing technology. We all know, what a queueing module is. It queues stuff, right? Who would sell queueing technology, that is useless? Anyway, the architect would just say, "ok we buy or make a queueing module". No problem, next? If they would buy one, it would of course be a useful queueing module, because no one sells useless queueing modules. If they would create one themselves, it would be the problem of the software main designer to design it and programmers' job to program it.

    When a customer asks for a queueing module, the architect just says "fine, its not a problem". If a wall had a regulation of fire safety, so what? Then it had. All the safety instruction would be added to the manual of the system. If the customer wanted a house made of paper, the architect would not hesitate. Its not the problem of the architect what the customer would do with a paper house. There are business analysts for that. The business analysts would know that the customer has an exhibition of old japanese buildings, so it would be perfectly logical to build the paper house.

     GajaKannan wrote:
    I agree, the entry costs of JEE platform is very high, and .NET is starting to increase the learning curve.  Although not a scientific fact to support, my observation is that, complex the platform, it has higher respect in the industry.  There is still a dogma for MS technologies being only a pretty user interface platform and less of enterprise grade, compared to JEE even though has terrible user interface richness, but celebrated in the industry just for being enterprise grade, in this case enterprise grade is more complex.  There are enterprise architects that told me that they would not use Ruby on Rails because it is suited only for small scale applications and not ready for enterprise grade till rich frameworks evolve.


    I think there is no reason what so ever for the platform to be complex. Capable yes, complex no. If I could create applications by pressing one button only, I would be happy as long as the applications meet all the customer requirements.
    Wednesday, July 2, 2008 3:56 PM
  •  Silvercode wrote:

    If you do dotNet applications, then there is pretty much obvious solution to select MSMQ.

    Abs. not. Just because I maybe using .net doesn't mean that my solution doesn't have to worry about other issues or systems. Perhaps MQ-Series messaging without MSMQ. Perhaps SQL Server Broker. Perhaps an in memory FIFO. Would I plump for a SQL Server Broker mechanism without every having tried it, for me abs. not. Would I use MSMQ without having tried it, again no. Does that mean if I was the arch' then I would have to go away and develop it, again no. But I'd feel like a fool if I'd recommended a technology that wasn't fit for purpose, in order to mitigate that risk I like to have had some experience in it.

     

     

     

    Wednesday, July 2, 2008 4:08 PM
  • Its true that people want to try out things before using them. But that is too slow. I think that the corporation where the architect is working in should have a database of ready tried out technologies and widgets with summary listings of properties. That way the architect wouldn't have to try everything. For example if the corporation techies had rated some technology "Failed" or "Bad", the architect could just pass it and select an another technology. This way the corporate could also hire more general architects instead of lots of platform specific architects.
    Wednesday, July 2, 2008 4:29 PM
  • That's an interesting idea, and since I think you certainly need a catalog of existing technologies then that would go some way towards that. It needs a way to introduce new technologies otherwise you'd run the risk of becoming too blinkered. Although, as we've discussed before, there are a number of occasions where the technologies are already set in stone so the arch' job is chosing the specific ones and connecting them together.

     

    It would be interesting to consider how other people would respond to that. Ultimately the whole web is full of this sort of Failed/Bad/Good and you'd obviously question those results. For me I think it would be a great thing to have but I can't help thinking I'd be siding on the, "if you want a job done properly..." approach of only really trusting something I'd tried.

    Wednesday, July 2, 2008 4:39 PM
  • Surely you would want to try yourself new things before trusting them. But I think about the corporation as a whole. You could go try things in your spare time or at an other company. But when you go to the company X where things are done by using the corporate tech catalog without spending company time on reanalysing it by normal architects, you would have to trust the catalog or go back into your ordinary company. Then the ordinary company and the cataloging company would compete with their Business Strategies, and the better would win.
    Wednesday, July 2, 2008 4:57 PM
  • I believe in a idealistic corporation there will be a rating for technologies that are failed or bad.  Although I have not seen one exist.  Especially in software there is no failed or bad technology.  It is how the technology was implemented in the current stack.  We have retired some technologies in the organizations that I worked based on the rating scale we use.  I know from my friends and peers that the same technologies were ranked best in other organizations based on their rating scale.  Ofcourse the rating scale is opinionated (all humans have bias cant separate that out) and secondly how it is implemented and how it fits your needs are usually unique.

     

    A final thought, how can a technology be failed or bad.  If I quote from your earlier post,

     Silvercode wrote:

    Now the queueing technology. We all know, what a queueing module is. It queues stuff, right? Who would sell queueing technology, that is useless?

    So how can anything be bad or failed, if everyone sells only useful stuff...

     

     

    PS: I completely agree with pkr.  I would not just pick MSMQ because it is .NET solution.  I would list out the same options he listed and compare the benefits of each one of them.

    Wednesday, July 2, 2008 9:18 PM
  • Well if all sold technologies are functioning, the rating catalog would still serve the purpose of assuring architects not wasting time to reanalyze the technologies just because they don't trust a technology. Plus the catalog would have all the necessary properties of the technologies based on the science of engineering, not based on mystic proprietary platform specific issues.

    We can see possible failures from the vendor image. If a vendor has no references and looks like going out of business, it is labeled as "About to fail". But when we consider any major technology vendor, they are pretty much assuring just by being a major one.
    Thursday, July 3, 2008 6:35 AM
  • I am not picking on your response.  I like your thoughts, so please keep your response flowing.

     

     Silvercode wrote:
    We can see possible failures from the vendor image. If a vendor has no references and looks like going out of business, it is labeled as "About to fail". But when we consider any major technology vendor, they are pretty much assuring just by being a major one.

     

    Does this mean, as an Architect I would only use major technology vendor.  If that was the case SalesForce.com would not be in accepted as much as it is today if people were looking on traditional on-premise solutions pre SAAS days.

    I agree, I would not pick a vendor that is going out of business.  On the other hand, I do look at multiple vendors in the domain, not just major technology vendors.

    Thursday, July 3, 2008 2:27 PM
  • Of course there are also small companies rising up and prospering, for example Google was small at first. But still I would count on technologies and companies that have been around for at least some time, because they need some success to proove that they are capable. Small companies get small projects at start, but big corporations should not rely on small brand new vendor start ups. Big corporations can test new technologies and rate the technologies according to tests and according to pioneer projects.

    But what about platform independence? It is completely possible to achieve platform independency in higher level of abstraction. With platform independence the architect can consentrate on architectural issues and leave the platform specific issues to main designer and code generators or such. Striving for platform independence the underlying technologies will be guided more towards supporting the science of software engineering instead of messing things the way the vendors want.
    Thursday, July 3, 2008 4:35 PM
  • I don't agree with the big/small argument. There are certainly pro's & con's of both but I'm quite happy to use a

    company I trust, and for me that can mean a number of things. For example, if I was to buy a nice little tree view widget do I get the source code? If I do then I immediately feel better about using it. I do agree that I want to use tried and tested technologies (by other people) that makes me feel comfortable too because other people will have hopefully found the problems and if they've not been solved then at least it's likely they'll be publicised. However, none of this implies big/small companies. How likely am I to be the farm on SQL 2008...not yet I won't. It might be worth spawning a new thread on this because it is an interesting topic but I fear we're hijacking this thread to talk about trust issues.

     

    Thursday, July 3, 2008 4:48 PM
  • Being a major vendor doesn't necessarily require to be big. For example some smaller companies are big enough in certain specific fields of interest.

    Being big/small has some effect on platform independency. For example are smaller companies ready for what it takes to take our industry to the next level? Smaller firms tend to be like hand crafting workshops who just bang at things. Bigger companies at least have the potential of becoming vendors who apply standards that are needed for more scientific engineering and industry production. Bigger companies have resources for enhancing the way things are done while the smaller ones mostly try to stay alive and / or grow bigger.

    Big/small applies to suppliers, vendors, and customers, because every one of them have a word about how things are wanted to be done. If a vendor buys non standard solutions from a supplier, then the supplier has a chance to change it to a standard solution. If a customer is buying a non standard solution from the vendor, then the vendor has a chance. The best situation would be that the customer knows something about the science of engineering and demands things are improved, the vendor wants to improve things too, and the supplier has also the same opinion.
    Friday, July 4, 2008 9:19 AM
  • Where development is no more development and becomes sell and buy: of software and people.

     

    Once upon a time they used to say: there is more to programming than programming. Nowadays this new generation of self-claiming experts of what they will not learn is used to say: let's go to the shop, but be it a good shop!

     

    I wouldn't be surprised if they are going to invent critics and holliwood of the good component shops, and glamour and gossip. It is so nice to be shopping.

     

    -LV

    Friday, July 4, 2008 4:59 PM
  • Yes but some one is still going to build the things that are bought. Progress happens and we have no reason to stay in stone age of software engineering.
    Friday, July 4, 2008 6:19 PM
  • Silvercode:

     

    > Yes but some one is still going to build the things that are bought.

     

    I wander who do you mean.

     

    > Progress happens and we have no reason to stay in stone age of software engineering.

     

    I wander which progress you are talking about.

     

    -LV

    Friday, July 4, 2008 6:58 PM
  • Well, you talked that development will be no more when people just buy and sell stuff like components. So I say development will not die, because if architects buy platforms instead of building them, some one is still going to have to build the platforms.

    And future progress is in platform independency where architects concentrate more in science and architecting itself instead of trying to adjust non standard components together.
    Friday, July 4, 2008 7:29 PM
  •  Silvercode wrote:
    Well, you talked that development will be no more when people just buy and sell stuff like components. So I say development will not die, because if architects buy platforms instead of building them, some one is still going to have to build the platforms.

    And future progress is in platform independency where architects concentrate more in science and architecting itself instead of trying to adjust non standard components together.

     

    Nice. Actually, the nicest proof I have seen so far that software architecture does not exist.

     

    -LV

    Friday, July 4, 2008 7:40 PM
  •  LudovicoVan wrote:
    Nice. Actually, the nicest proof I have seen so far that software architecture does not exist.

    -LV


    Software architecture exists, but it is moving to a more higher level of abstraction. That movement will not delete the previous layers of abstraction either. There will be program code below the hood always.

    Friday, July 4, 2008 8:10 PM
  •  Silvercode wrote:
     LudovicoVan wrote:
    Nice. Actually, the nicest proof I have seen so far that software architecture does not exist.

    -LV


    Software architecture exists, but it is moving to a more higher level of abstraction. That movement will not delete the previous layers of abstraction either. There will be program code below the hood always.

     

    You mistake software architecture for playing lego. But software is not made of bricks, and that's the biggest mistake and source of problems. Of course there are companies who mostly work by personalizing third party components, and that's indeed not software development. Your software architect may be a great lego player, yet "software" is fundamentally improper there. Software happens "below the hood" only in that, somewhere else, someone had to develop it. Did they have an "architect" in the team, BTW? Certainly not, even according to you.

     

    -LV

    Friday, July 4, 2008 9:38 PM
  • I am not mistaking software architecture for playing Lego. I am just saying, that software architecture can be like playing Lego. Anyway, when children build stuff from Lego, they actually are building something and they have never built even a single Lego brick.

    The biggest mistake and source of problems is exactly the fact, that lots of software is not made of bricks or components.

    Even today there exists fourth generation programming languages that have many ready made widgets like scroll bars, buttons and combo boxes. So the direction is towards more brick like construction anyway. We just add more layer to the abstraction. We need business logic widgets too, and there is already business rule engines and workflow foundations. In order to use the business logic widgets and foundations we need to depict the business rules somehow and there we use models. Models offer us platform independency when we standardize the platforms and model languages.

    I think
    main software architects of companies have great role in steering the development towards using better foundations, rule engines, and models by researching what is available and by participating to community discussions. Normal software architects have the role of getting information from the main architects and putting software projects under these new approaches.
    Saturday, July 5, 2008 5:32 AM
  • Silvercode:

     

    > I am not mistaking software architecture for playing Lego. I am just saying, that software architecture can be like playing Lego.

     

    It just cannot. Can you get it? Need some explanation/clarification? (Can you for instance even get why model driven development is still not with us?) Don't be shy, just stop talking and start listening: it's telling your nonsense loud that should ashame you.

     

    Thinking of software as made of bricks is a deep mistake, actually the biggest and most widespread mistake. Can you get it/why?

     

    > Anyway, when children build stuff from Lego, they actually are building something and they have never built even a single Lego brick.

     

    Software is just not like bricks, and this lego analogy with bricks is as easy as it is mistaken: indeed the easiest analogy for the incompetent, still the wrongest analogy possible as far as software is concerned.

     

    > The biggest mistake and source of problems is exactly the fact, that lots of software is not made of bricks or components.

     

    You simply show that you don't know what you are talking about. Thinking of software as made of bricks is a deep mistake, actually the biggest and most widespread mistake.

     

    > So the direction is towards more brick like construction anyway. We just add more layer to the abstraction.

     

    You just don't know what you are talking about. Thinking of software as made of bricks is a deep mistake, actually the biggest and most widespread mistake. And your idea of abstraction as a bunch of layers one on top of the other, is at least as mistaken. You simply have no idea what you are talking about.

     

    > We need business logic widgets too

     

    You just don't know what you are talking about. A perfect supporter of "the Java community", BTW.

     

    You don't need to be a software guru to guess that there *must* be a reason why the software industry is sinking; the reason is simply in the deep level of incompetence that has flooded it.

     

    You just don't know what you are talking about: *You* are the biggest problem for this industry.

     

    -LV

     

    P.S. "Sometimes technical words are spelled the same as words used in ordinary discourse, but they have different meanings."

    Saturday, July 5, 2008 6:53 PM
  •  LudovicoVan wrote:
    It just cannot. Can you get it? Need some explanation/clarification? (Can you for instance even get why model driven development is still not with us?) Don't be shy, just stop talking and start listening: it's telling your nonsense loud that should ashame you.


    No wonder our field of industry is not developing because there exists such major stubborness. Of course we can build software like playing Lego. Please explain why we couldn't? Surely the development is not just child's play with Legos, but we are going to use more components, models, generators, and engines in the software industry.


    Model driven development is not with us, because its new and still under development. But model driven development has taken many steps and it is used to some extent already in some pioneering companies. And in embedded systems model driven development is already happening and is now the norm - or at least in some advanced big companies, not in average garage companies.

     

     LudovicoVan wrote:
    Thinking of software as made of bricks is a deep mistake, actually the biggest and most widespread mistake. Can you get it/why?

     

    Well, according to my knowledge model driven development is rising.


     LudovicoVan wrote:
    Software is just not like bricks, and this lego analogy with bricks is as easy as it is mistaken: indeed the easiest analogy for the incompetent, still the wrongest analogy possible as far as software is concerned.


    Software is of course complex, but the complexities are always fought against. In the point where software complexity goes too far in an application's program code, that fight has been lost.

    For example maintaining an old Active Server Pages site can be a nightmare. Good architecture helps, but in any case it is preferrable to use components that encapsulate functionality. Designers and programmers try to use components in any other environment too. Have you heard about object oriented programming? Or functions? They both use components to reduce complexity. Objects and functions = bricks (or other building material).

    And now when we get to components, of course in many cases the components are modeled with for example UML (Unified Modeling Language). I think these things should be basics? You know about this stuff, right?

    You just skipped my words about business rule engines and such. Why? Tomorrow's business software is not even designed like software used to be designed. Instead business analysts or their assistants are able to input all the business rules directly to Business Rule Databases. How about that? Then they use also business process models to model the "software" that is the business processes and rules.

    There are even more and more examples of platform independency. And no, I am not talking only about Java, but independency of .NET / JEE. There is no point to carve business logic into rock, but keep business logic in a separate layer or database.

     

     LudovicoVan wrote:
    You simply show that you don't know what you are talking about. Thinking of software as made of bricks is a deep mistake, actually the biggest and most widespread mistake.

     

    Stubborness and not seeing the wall from bricks is also a big problem.


     LudovicoVan wrote:
    You just don't know what you are talking about. Thinking of software as made of bricks is a deep mistake, actually the biggest and most widespread mistake. And your idea of abstraction as a bunch of layers one on top of the other, is at least as mistaken. You simply have no idea what you are talking about. - -


    Layers of abstraction are used like I have described, like it or not.

     

     LudovicoVan wrote:
    You don't need to be a software guru to guess that there *must* be a reason why the software industry is sinking; the reason is simply in the deep level of incompetence that has flooded it.


    Yes there is lots of incompetence in the field of software engineering. But still model driven development makes things better even for the successful people.

     

     LudovicoVan wrote:
    You just don't know what you are talking about: *You* are the biggest problem for this industry.

     

    I don't say that model driven development and such is easy. And I don't trust anything that doesn't work. But there is already some success stories.


     LudovicoVan wrote:
    P.S. "Sometimes technical words are spelled the same as words used in ordinary discourse, but they have different meanings."


    So?
    Sunday, July 6, 2008 6:44 AM
  • Silvercode:

     

    > No wonder our field of industry is not developing because there exists such major stubborness. Of course we can build software like playing Lego. Please explain why we couldn't? Surely the development is not just child's play with Legos, but we are going to use more components, models, generators, and engines in the software industry.

     

    Sure, who needs Lego? Let's just have this room with one single big red button in it. What fun.

     

    > Model driven development is not with us, because its new and still under development. But model driven development has taken many steps and it is used to some extent already in some pioneering companies. And in embedded systems model driven development is already happening and is now the norm - or at least in some advanced big companies, not in average garage companies.

     

    You simply don't know what you are talking about. What is already happening is what has always happend: some people play the room with big buttons, some people behind the hood do the dirty work and get things done.

     

    > Well, according to my knowledge model driven development is rising.

     

    Your knowledge about what's on sell is indeed irrelevant to the model driven paradigm.

     

    > Software is of course complex, but the complexities are always fought against. In the point where software complexity goes too far in an application's program code, that fight has been lost.

     

    If you had any idea what the term "software" really entails, you would at least know that our only true complexity comes from the problem domain.

     

    > For example maintaining an old Active Server Pages site can be a nightmare. Good architecture helps, but in any case it is preferrable to use components that encapsulate functionality.

     

    Only if you happen to know what to embed and for what functionality. You mistake what is auxiliary for what is primary, and back.

     

    > Designers and programmers try to use components in any other environment too. Have you heard about object oriented programming? Or functions? They both use components to reduce complexity. Objects and functions = bricks (or other building material).

     

    Perfect, I was indeed waiting for that: the semi-permanent damage!

    > And now when we get to components, of course in many cases the components are modeled with for example UML (Unified Modeling Language). I think these things should be basics? You know about this stuff, right?

     

    You must mean that thing that now only seems to support OO constructs? Sure.


    > You just skipped my words about business rule engines and such. Why? Tomorrow's business software is not even designed like software used to be designed. Instead business analysts or their assistants are able to input all the business rules directly to Business Rule Databases. How about that? Then they use also business process models to model the "software" that is the business processes and rules.

     

    You don't know what business rules are and where they come from. You keep dreaming about a room with a big red button within.

    <snip>

     

    > Stubborness and not seeing the wall from bricks is also a big problem.

     

    You might have glimpsed the wall. That there are bricks there is your very dream.

     

    > Layers of abstraction are used like I have described, like it or not.

     

    You might call them layers of abstraction as much as you can call them deep fried bananas: that's the point.

     

     LudovicoVan wrote:
    P.S. "Sometimes technical words are spelled the same as words used in ordinary discourse, but they have different meanings."

    > So?

     

    So what?

     

    -LV

    Monday, July 7, 2008 12:27 AM
  •  LudovicoVan wrote:
    Sure, who needs Lego? Let's just have this room with one single big red button in it. What fun.


    There are components, models, generators, and engines in the software industry today. Do you still think that having and using components, models, generators, and engines is impossible?

     LudovicoVan wrote:
    You simply don't know what you are talking about. What is already happening is what has always happend: some people play the room with big buttons, some people behind the hood do the dirty work and get things done.


    I have said that while more layers of abstraction is added to software development, there still will be program code and people who have to develop it. But using components and engines need an architect too. For example when skyscrapers are built, they use blueprints and components too. In software engineering the models are like blueprints and components are like building components. Even while skyscraper builders use blueprints and building components, they still use an architect.

    You said that this separation of creating components and creating software has always been there. Yes that is true, but the separation is going to be wider. In fact, if you compare plain application programming with using models and engines, then the wider separation is already in use in many companies. Some companies still build software the old way and say its the only way reasonably possible, even though there are companies that build software the new way.

     LudovicoVan wrote:
    Your knowledge about what's on sell is indeed irrelevant to the model driven paradigm.


    Knowledge about what's on sale is not irrelevant, when people start using the components. Also when the components exist and people are using them, we can see that model driven paradigm is happening.

     LudovicoVan wrote:
    If you had any idea what the term "software" really entails, you would at least know that our only true complexity comes from the problem domain.


    If software developers use bad architecture or do things with lower generation languages, the software is more difficult to develop and maintain even if the software does the same things than with good architecture and higher generation languages. This is obvious and gets more clear when project sizes grow.

     LudovicoVan wrote:
    Only if you happen to know what to embed and for what functionality. You mistake what is auxiliary for what is primary, and back.


    Yes you shouldn't have components only for the sake of having components. But in general gaining good structure is sought through having for example components and or models, engines, ..., because there are not much other ways and those are the ways after coding practices and such has already been applied.
     
     LudovicoVan wrote:
    Perfect, I was indeed waiting for that: the semi-permanent damage!


    What do you mean by semi-permanent damage? Well, what ever you mean, that won't stop people using object oriented programming, components, and functions when they are improving the development process.

     LudovicoVan wrote:
    You must mean that thing that now only seems to support OO constructs? Sure.


    UML is not perfect, but it is used, because it helps in modeling. Even though its not perfect, that doesn't mean it cannot be used. And it or some other modeling language will be developed further.

     LudovicoVan wrote:
    You don't know what business rules are and where they come from. You keep dreaming about a room with a big red button within.


    Talking about business rule engines is not dreaming about big red button but talking about business rule engines. They exists already and can and have been used. Business rules come from business people and like.

     LudovicoVan wrote:
    You might have glimpsed the wall. That there are bricks there is your very dream.


    If a wall is not made of bricks, then it is for example a concrete wall that has been molded. But there are machines that can mold.
     
     LudovicoVan wrote:
    You might call them layers of abstraction as much as you can call them deep fried bananas: that's the point.


    Layers of abstraction are layers of abstraction, that is the point.

     LudovicoVan wrote:
    So what?


    So tell me what you mean by "Sometimes technical words are spelled the same as words used in ordinary discourse, but they have different meanings."?
    Monday, July 7, 2008 6:02 AM
  • Silvercode:

     

    > There are components, models, generators, and engines in the software industry today. Do you still think that having and using components, models, generators, and engines is impossible?

     

    What is impossible is the last step: getting from there to the room with one big red button to push, otherwise "pure model driven" as you might like to call it. With an analogy, the situation is not different than when you rush up on a project and find yourself in troubles on the last 10-20%: the more you have been quick, the more you are stack. And then you can glimpse that there is no enigma behind software project failures, just a hugh massive flooding amount of incompetence and ignorance of even the most basic principles and elementar facts that make up this discipline.

     

    > I have said that while more layers of abstraction is added to software development, there still will be program code and people who have to develop it. But using components and engines need an architect too.

     

    Yeah, keep dreaming about your big red button, you big self-crowned software architect. Someday someone is gonna build it, you are gonna buy it, and then you might even push it.

     

    -LV

    Monday, July 7, 2008 6:42 PM
  •  LudovicoVan wrote:
    > There are components, models, generators, and engines in the software industry today. Do you still think that having and using components, models, generators, and engines is impossible?

     

    What is impossible is the last step: getting from there to the room with one big red button to push, otherwise "pure model driven" as you might like to call it.


    There is already components, models, generators, and engines today, so there is no last step that has not been done. Every step has been done. Of course pure model driven approach is in many cases too heavy, but that doesn' t mean that model driven development cannot happen. There are success stories that have cut development time significantly where thanks goes to MDD.


     LudovicoVan wrote:
    With an analogy, the situation is not different than when you rush up on a project and find yourself in troubles on the last 10-20%: the more you have been quick, the more you are stack.


    The situation is different and the means are different. For example if we want to build a business system, we only need some engine and input all business rules and models there and there we have it. But if we want to do complex programming with C, then we have to go back to traditional methods unless we have some huge project that has resources to develop helping tools besides the traditional methods.


     LudovicoVan wrote:
    And then you can glimpse that there is no enigma behind software project failures, just a hugh massive flooding amount of incompetence and ignorance of even the most basic principles and elementar facts that make up this discipline. - -

     

    Software projects can be and have been improved with MDD.

    Monday, July 7, 2008 7:37 PM
  • Silvercode:

     

    > so there is no last step that has not been done.

     

    Cool. You know, I too believe all there is to do is indeed a step back.

     

    > For example if we want to build a business system, we only need some engine and input all business rules and models there and there we have it.

     

    You keep dreaming, of an improductive dream. There is no such thing yet, and in such terms there will never be.

     

    -LV

    Monday, July 7, 2008 7:57 PM
  • Yes there is. Of course its not quite that simple to use, but the basic principles goes like that. Even I can build one.

    Lets take a database. Create tables for business rules. Then create software that executes those rules. Input the rules, and its done. This was my 20 second plan. Others have used hundreds of thousands of hours building such things, and they are quite advanced.
    Monday, July 7, 2008 8:32 PM
  • Silvercode:

     

    > the basic principles goes like that. Even I can build one.

     

    Don't be fool.


    > This was my 20 second plan.

     

    And that's what you can produce.

     

    > Others have used hundreds of thousands of hours building such things, and they are quite advanced.

     

    Quite advanced gives a good idea.

     

    One day your heros are gonna win.

     

    And you'll be there finally pushing that big red button.

     

    Have a nice day in the meantime.

     

    -LV

    Monday, July 7, 2008 8:37 PM
  •  LudovicoVan wrote:

     Silvercode wrote:
     For example if we want to build a business system, we only need some engine and input all business rules and models there and there we have it.

    You keep dreaming, of an improductive dream. There is no such thing yet, and in such terms there will never be.

     

    I have to agree with Silvercode on this.  What Silvercode has mentioned in the above is the highly matured BPM solution.  I did not have a luck in working on one of the matured state BPM solution yet, but do have friends/practioners that has first-hand experience of implementing and supporting those solutions.  In those shops IT/Technology is an enabler of business strategy.  It is not a dream.  Hoping that will never happen is an improductive dream Smile

    Monday, July 7, 2008 9:19 PM
  • Silvercode, I think you're on the right lines. Business software is there to enable business' to carry out their tasks. As such it should ideally be maintained by the business not by programmers desparate to justify their jobs. Ideally there shouldn't be any compiling or big buttons, the business analysts should be able to maintain the systems themselves at the context of their own domain. However...I don't believe we're there yet. There are products that do more or less in fairly narrow parts, products that help plumb them together and manage to do that at the domain somewhere between the developer, system admin and business analyst. But I agree that ideally we should be striving to the goal of configuring rather than developing but it might never be achievable. Afterall we've come a fair way from punch cards and no OS building blocks and we've got far more tools/services/lego bricks to help us stop reinventing the wheel and concentrate on the problem domain rather than the plumbing.

    [Edit] Can we also keep the topic title in mind as we're at risk at hijacking this thread
    Monday, July 7, 2008 9:34 PM
  • Right, we are not there yet, and many companies are just waiting that a miracle happens for us to get there. I think we should try to go the new way. There are already many conventions if not standards and there are many tools and engines that we should start practising to use.

    We still need normal architects and designers
    in the transformation phase, but they should start using models and engines.


    Many times when software is being built, there are not that much business analysts. Lots of smaller companies tend to build software so that there are some kinds of developers and project management people and customer's business and technical representatives, but no actual business analysts doing business analysis.

    We need to increase the amount of business analysis and add business analysts to the projects. We need to do business process management increasingly. Eventually this leads to moving more responsibility of creating / managing software / automating business processes to the business analysts and business people. Business people cannot use too much time engineering the business with the business analysts - after all business people are doing business. So, there needs to be business architects and business engineers, who help all those business people and analysts.

    The need for change rules over platfrom nitpicking and the solutions are derived from science. Businesses really do want systems that are easier to be changed, because the speed of change has increased in business. The speed doesn't come free of cost, though you still can achieve savings from being able to change the system easily. But in order to change the system, the businesses need work force to do the changes. So, some system and software architects move to technology end user businesses and architect, design, and maintain business rules and engines there. Problem solved.


    Of course today many companies buy ready made systems like customer relationship management systems and get the business rules with the systems. No need to input anything, when everything has been put in already. But this doesn't stop system vendors from selling business engines filled with initial business rules, that are just maintained and further developed at the end user site.


    What comes to platform independency, we have discussed this already. New layers of abstraction are founded so that business rules and business logic are kept independent of the target platform. Surely there still will be normal software development, but we need to admit that business applications are one big field that we need to handle too.

    Now there already are success stories of separating business logic and rules so that we have platform independent models that are used as the basis of the systems being built. And there are generators that transform those models with the help of a designer into the target platforms.

    We see two kinds of platform independency here:

    1) Separating business rules from the software and using business engines instead. With this solution you can more easily maintain the business rules and move the rules into new engines, if need be, instead of rewriting everything once in a decade.
    2) Separating the software model into platform independent and platform specific models and using generators and designers to transform the models to different platforms. With this solution you have better view of your software structure plus you have smaller cycle times from design (model) to solution (software). Also you can deliver your solution more easily to many platforms at the same time.

    Software designers can start designing software already before it has been decided to use one or other platform. And if there will be new platforms in the future, just write a new transformation tool for it. Plus there needs to be actually only one transformation tool in the world to do the trick. Everyone can use that same tool, because it can be bought or if it is free, just copied. Designers can concentrate on creating software models, and tools take care of the platform specific implementation intricacies like stubs, skeletons, markings, and whatnot.

    Tuesday, July 8, 2008 8:45 AM
  • ...but currently we're still building those applications so we do need to be concerned about lower level technology. So today it is an advantage for an Arch' to be technology agnostic.
    Tuesday, July 8, 2008 11:33 AM
  •  pkr2000 wrote:
    ...but currently we're still building those applications so we do need to be concerned about lower level technology. So today it is an advantage for an Arch' to be technology agnostic.

     

    "Agnostic" means not knowing, or simply: ignoring. Your statement above makes no sense.

     

    Back to the present discussion: there is NO RECIPE EVER for software production. At best, it is an Engineering. Should you get that, you would know why that big red button is just what it is: a childish dream.

     

    -LV

    Wednesday, July 9, 2008 2:08 AM
  • Ok, I'll explain what 'technology agnostic' means in this context. It means that initial designs/discussions shouldn't be driven/influenced by specific technologies, i.e. it should be ignored. Hope it makes sense now.

    re: Big red button. The hijacked discussion is no longer about a red button. It's a about an ideal of business analysts making their necessary changes without the need to worry about the underlying software/hardware.


    Wednesday, July 9, 2008 5:56 AM
  • pkr2000:

     

    > Ok, I'll explain what 'technology agnostic' means in this context.

     

    You mean you have maybe explained what *you* mean. Technology agnostic still means something else.

     

    > It means that initial designs/discussions shouldn't be driven/influenced by specific technologies, i.e. it should be ignored. Hope it makes sense now.

     

    It makes sense and actually is quite trivial and out of context. You are talking about the elementar and basic (foundational) distinction between the conceptual and technical levels.


    > re: Big red button. The hijacked discussion is no longer about a red button. It's a about an ideal of business analysts making their necessary changes without the need to worry about the underlying software/hardware.

     

    Who hijacked what is just in your judgement. Business analysis -- the concrete one, not any ideal whatsoever -- does not indeed need warrying *too much* about the underlying technologies, but even this, if taken too literally, is just wrong.

     

    As to the Software Architect (which has nothing to do with the classical notion of software having an "architecture"), as you see there is no place for him on board: its conceptual vs. technical, nothing in between. And then look at the various recipes around, and you'll see that they mess up with this fundamental notion from the very beginning, so being doomed to secure failure.

     

    Not that I expect you to finally agree, but I am confident we might at least get nearer to an understanding of the basic terminology.

     

    -LV

    Wednesday, July 9, 2008 9:21 AM
  • Here they think that technology agnostisism means that there was no central designer who created all the software technology, but the technology developed by time naturally and gradually. They think also that there is no exact meaning, but one meaning is for example that a sales person doesn't care what platform is used as long as he gets his product sold.
    Answer

     LudovicoVan wrote:
    Back to the present discussion: there is NO RECIPE EVER for software production. At best, it is an Engineering. Should you get that, you would know why that big red button is just what it is: a childish dream.


    I have said that I would be happy if I had only one button to push to get software. But I have never said that it is possible to have just one button. The idea of one button is supposed to mean that there is no reason to make things complicated if there is a simpler way.

    And usually there is a simpler way. For example if some new technology is added to software program code, then the end result is simpler if the new extra pieces of code are encapsulated instead of just being injected between the old code.

    Also there is absolutely nothing wrong with modeling. Of course things are modeled. Even more so in engineering than in crafting. If we want to call ourselves engineers, we need to start doing blueprints instead of plainly crafting stuff.

    We already know how to model software with for example UML. We get the models and add some abstraction of components, and then separate the roles between creating and designing software, and before we even notice, we have more or less platform independency.
    Wednesday, July 9, 2008 12:07 PM
  • Silvercode:

     

    > Here they think that technology agnostisism means ...

     

    Anybody can write a personal dictionary and maybe even permanently rewrite it in order to be always right: language is fluid enough. You guys should just stop kidding and take your responsibility. The point remains: we are (in general) software and information engineers, not a bunch of guys having a casual conversation in a pub, and "technology agnostic" in this context *does* have a specific meaning, that you guys know it or not. Try check your dictionaries instead of just looking for confirmations to your nonsense: yeah, the world is just a huge ball of nonsense, so anything can find support, even gas chambers, we already know that, don't we?

     

    > I have said that I would be happy if I had only one button to push to get software. But I have never said that it is possible to have just one button. The idea of one button is supposed to mean that there is no reason to make things complicated if there is a simpler way.

     

    You are gonna save this industry, now I am convinced. At least with your enthusiasm and positive attitude.

     

    -LV

    Wednesday, July 9, 2008 12:22 PM
  • When I was very young (4-5 years old, or something) there was this Manga cartoon on TV (the very first Manga on TV in Italy): Goldrake. Now, somewhere in the closing titles there was this picture of a section of the Goldrake robot and flying machine with all the wiring and internals pictured... I was used to tell myself: if that's how it is made internally, I should just get a picture of it, then I could copy the scheme and build back the machine!

     

    Later, I have discovered it was not that simple.

     

    -LV

    Wednesday, July 9, 2008 12:59 PM
  •  LudovicoVan wrote:

     

    You mean you have maybe explained what *you* mean. Technology agnostic still means something else.

     

     

     

    I'm fascinated to know what is means, please enlighten me.

     

     

    Wednesday, July 9, 2008 1:06 PM
  • pkr2000:

     

    > I'm fascinated to know what is means, please enlighten me.

     

    Means means: be serious.

     

    -LV

    Wednesday, July 9, 2008 1:52 PM
  • Ok, great, enough of childish playground antics. GajaKannan has created this post in the interest of discussing the question he posted. "I" suggest that if we want to talk about other subjects, because frankly this is a at best

    tenuously linked, then start a new thread.

    Wednesday, July 9, 2008 1:58 PM
  • pkr2000:

     

    > then start a new thread.

     

    I am afraid we have a different perception as to what is on topic and what is not, and above all about who has the right to say that to whom. You please feel free to go on and open a new topic if you like, I frankly couldn't care less for this reiterated blabbing.

     

    -LV

    Wednesday, July 9, 2008 2:04 PM
  •  

    > You please feel free to go on and open a new topic if you like, I frankly couldn't care less for this reiterated blabbing

    says the king of it.

     

     

    Wednesday, July 9, 2008 2:10 PM
  • In my dictionary agnostisism means that one cannot get information about super natural phenomena.

    Thanks but I cannot save the software industry
    alone. Happily I am not alone in this.

    I found this article that tells about service oriented architecture and services in the light of technological agnostisism. The writer, Dan North, tells that you should not make a Service out of something that is not in the business world terms. For example you have vacation application forms, that you fill up and send to a handler, in business. But you don't have technical stuff in business terms like data service or replication service. So for now we need to model only the business processes, which are business related and technology / platform independent. All the technology can be left for technology engineers and business engineers can take care of the modeling of business.
    Article

    So this is true. We really design business systems first platform independently, then build the systems into some platform according to the models.
    Wednesday, July 9, 2008 3:02 PM
  • Silvercode:

     

    > In my dictionary agnostisism means that one cannot get information about super natural phenomena.

     

    Your dictionary is quite correct: it is "agnostic" adjective, not "agnosticism" noun, which instead is a philosophical term.


    > Thanks but I cannot save the software industry
    alone. Happily I am not alone in this.

     

    Of course you have got your monkeys behind the hood, who between a banana and the next, will push your tricycle.


    > I found this article that tells about service oriented architecture and services in the light of technological agnostisism.

     

    "Technology agnostic" is what the article says. And it is just a tutorial. Welcome to the world of business analysis. And no, despite what they say to make it simple, that is too simple: if you have no idea about the underlying technologies, you are gonna be a disaster anyway, even if you know the business better than the client himself. Other thing is that a business analyst should tendentially never mention technical terms with the client: that's another story.

     

    But, anyway -- and I hope for you joy ---, if there is no more questions/objections, I am just out of this thread.

     

    So, please, enjoy your own conversation.

     

    -LV

    Wednesday, July 9, 2008 3:23 PM