AttributesClassesInterfacesAndTypes are not my concern. Not yet. Wish I know more though. Meanwhile ''A''''''greementAlignmentPoliciesAndRelationships'' are TheBigIssue''''''s. But I still claim to be a part-time SoftwareArchitect, because ArchitectsPlayGolf, in the RelationshipManagement sense. InformationTechnologyFrameworks, JavaAndDotNet, SecurityManagement, SoaIsNightSky etc are in my scope, and coding is not. ---- This page was intended to discuss with people that there are different types of SoftwareArchitect''''''s doing different things. Some ArchitectsPlayGolf, some ArchitectsPlayGod, and some ArchitectsJustPlay. EricHodges responded, and most of the page had been a dialogue with him. Unfortunately with WikiTechnology here anyone can respond, and therefore the page is getting more messy than it necessary. ''If so, then this page is poorly named. I'm loath to suggest such a long name, but ArchitectureIsNotAboutAttributesClassesInterfacesAndTypes perhaps better catches the meaning. There must be a shorter way to name this concept...'' ''Complete non-sense, ArchitectsPlayGolf and ArchitectsJustPlay are OrganizationalAntiPatterns. If you think that attributes classes, interfaces andn types are not your concerns, then you shouldn't be "architect". If you are in charge of picking up tools and technologoies, find your best developer, and ask for professional advice. Do not assume that if you can google for buzz-words, read expensive "industry reports" filled with trivialities at best, and more often than not with wrong information, then you have some kind of competence on judging the merits of technologies as they may apply (or not apply) to a software project. '' ''Now the extraordinarily funny MetaAntiPattern at work here is that the so-called "architect", not only applies anti-patterns in his parochial business environment, but wants to promote them urbis et orbis as "patterns" on a site like c2 (which is by programmers and for programmers). And in the process he deploys CollaborationAntiPatterns and even those he tries to promote as CollaborationPatterns.'' ''The resolution to making room for this viewpoint is quite easy: DavidLiuOnArchitecture, DavidLiuOnArchitects, because this is a fringe view that you have not put the least of efforts to back it up with reasonable premises, arguments and rational discourse. -- CostinCozianu'' And then there are software architects who wonder how anyone can call themselves a software architect without using the architectures they design and the tools they select. See repeat this (something similar in ArchitectsJustPlay). ''See repeat what?'' ---- I've never understood what someone could do with tools like JavaAndDotNet if AttributesClassesInterfacesAndTypes were not their concern. How do you use them? -- EricHodges The statement at the top is probably an extreme form of rhetorics. * Having said this, I would suggest the (top section) statements draw attention to the fact that architectural projects need to be started in TopDown manner. * At higher level, StrategicAlignmentOfItProductsAndServices, BusinessValue, and GovernanceVsManagement issues are on focus and need to be resolved. * Subsequently, on the issue of SystemsArchitecture, one need to examine alternate desired and achievable target frameworks. A reference technical architecture need to be built with consideration of funding and ChangeManagement concerns. * A key aspect is legacy considerations. One does not go about implementing a ServiceOrientedArchitecture, if CulturalReadiness is lacking. Lots of projects fail due to failures in achieving the cultural change in a timely fashion. * Legacy considerations also include analysis of skills and synergies. For example, if EssentialSkillsForAgileDevelopment is nonexistent, then perhaps it is not yet time to consider a JavaPlatform, if you haven't got one already. So maybe it is forget EnterpriseServiceBus, and consider EnterpriseApplicationIntegration instead. Sometime later, the architects come to more technically relevant areas. This is the intense "Golf playing" stage. Middle user management (lots of people) make or break "proof of concept" and QuickWin projects, so it may be necessary to GetIndividualBuyInBeforehand. There is already a business endorsed ApplicationArchitecture in place, and some funding prioritization to make the transition (from here to there). Assume there is already senior (perhaps board level) support for the aquisition (and implementation) of an EnterpriseResourcePlanning package. There need to be exercises to examine what specific functions to acquire and implement. The "Golf playing" include the networking with peers in other companies, to understand what and how things might work, what level of user participation is needed when, whether you need interim technologies / solutions. Inhouse people, architects included, just do not have all the required knowledge of solutions and their limitations. This is also the stage the architectural team need to work with "delivery areas" (application and enduser) to agree on resource and schedules. A proposal is needed for signoff, to obtain reaffirmation of the business commitment, and to start dependent processes which can include partnering and tendering. There may be some consideration of AttributesClassesInterfacesAndTypes, but these are probably limited, and pale in size compare to policies, contracts, agreements, services, etc. -- AnonymousOnPurpose ''Are you arguing in favor of a class of software developer composed of people who don't actually devlop software, but make decisions about which tool sets actual developers will use without having first used them? If so, how do members of this class of "developers" learn about the tool sets? Read magazines? And why would anyone who has to write code trust their decisions? -- EH'' * Oh, because of stories like this one: http://www.kuro5hin.org/story/2005/9/27/95759/4240 need to happen. With "strategic alignment" and all the rest of BS. ** In this instance I would congratulate CC for coming up with a recent link to share. I read it and enjoyed the article tremendously. ** Assuming a genuine and reasonably balanced report. Situations like this can indeed develop. I think it could be a story repeated over again with changes in vendor names and companies. I can quote you a few myself. ** However my initial reaction is that the ''' problem started with the deficiencies Governance / IT alignment stage.''' And not helped by the knowledge that the company has lots of cash to burn. I had a discussion with a colleague who had decades of IT experience, different from mine, about the two step process. He remarked that in his experience, "sometime later" statement made above was actually a "parallel exercise" in the real world. My reaction at the time was "it takes lots of time to address internal relationship issues". How long? I can say that in my experience one senior manager confirmed in one organization that four years after the initial creation of the "Governance model", they are beginning to put this into practice. Cultures do not change overnight. But that does not mean all development stand still. It just meant make sure the culture is right before you undertake massive infrastructure projects.. if you can. ---- '''CollaborationStartsWithaQuestion''' But the above can become an OverextendedArgument. "From above" ''...If so, how do members of this class of "developers" learn about the tool sets? Read magazines? And why would anyone who has to write code trust their decisions?'' I suggest it is time you provide some insights to the excellent question above, as to how things might work instead. And it would be better if the scenarios are realistic. ''I asked the question for you to answer. The obvious alternative is to refuse to call people who don't develop software "software developers". Programmers should pick their tool sets based on first-hand experience, not marketing or journalism. I wouldn't buy a car based on the recommendation of someone who didn't know how to drive. -- EricHodges'' It is time people who value this community to reassess whether their behavior can be construed as HostileStudent, HostileTeacher or similar agressive manners. If I recall correctly when I asked you information on EJB, in the Costin challenge KB case, you were not nearly as enthusiastic about providing assistance. I will soon be responding to DaveVoorhis on his question and in Costin's words "put in the shoes of WikiReader", how annoying the questioning tactics were used. You are much better for now, and I acknowledge it is a "valid" viewpoint not to buy cars from recommendation of people who do not know how to drive. We can continue a yes/no argument like CC and RK is having now, but would you not consider ToFightEvilWorkOnTheGood could be better for the community. ''Huh?'' Earlier I said the following and still feel this is how things work in reality. Programmers do not pick tools. Programmers apply tools the best they can, based on software dictated to them by much higher up. The higher ups get their ideas from conferences, presentations (vendor), visits (other companies, vendor labs), their business colleagues who want products only one vendor can provide, paid consultancy studies etc. I am qualified to say the above because I have worked in various medium to large companies for many years. Inhouse technical staff are often snowed by vendor heavies sent in at product demo (proof of concept, etc) time. This has nothing to do with my personal view, nor the view of any other people, whether this is how things should work. So I keep focused on "what is realistic now and in near future", and talk to people sitting around me (and they all happen to write code, for different platforms). ''I assure you that programmers pick their tools. I've picked every tool I've ever learned, and it's been 15 years since someone "higher up" tried to tell me which tools to use. I have also worked in various medium to large (5,000 to 100,000 employee) companies for many years. But I'm still a bit confused about how you learn about tool sets. The people sitting around you write code, so they must be programmers, correct? But programmers "do not pick tools", so they are using tools "dictated" to them by non-programmers, also correct? If so, why do you trust their judgement about tool sets? And how do you know their assessment is accurate? -- EricHodges'' This is one of those rare moments where you tried harder than me to explain viewpoint. What do you mean "how I learn about tool sets". The first tool I used was Fortran decades ago. The first tool I use at work is Apl, decades ago and none of the programmer types there made the choice of tools. And when I came to participate in the evaluation of tools there were lots of constraints put on our team by all stakeholders, and that was only proper. Now please tell me what do you mean by your 100,000 employee firm go about letting programmers choose their tools. Is it possible you worked for a consultancy selected by a 100,000 employee firm to do software evaluation. ''I'm not asking about the tools you've used. I'm asking about the tools you say you don't use. How do you learn about a tool without using it? From everything you've said it sounds like you trust the knowledge of others. From your actions on this wiki it seems like you want us to research tools for you. Why not get your hands dirty and use these tools yourself? Then you can come back and tell us what you think.'' ''I was one of the 100,000 employees. That employer let me pick my tools. I was not a consultant. I was an employee.'' -- EricHodges ''In my experience, the degree to which a developer gets to choose his or her own tools depends on the project, the company policy, and the seniority of the developer. If some combination of these results in a developer (or a set thereof) not being free to choose his or her own tools, it is typical for the toolset to be chosen by some technically astute body, with at least some, and frequently all, input from other programmers. The reason for this is simple -- the average non-technical manager is more than aware that he or she isn't qualified to recommend one programming language over another, and is likely to face resistance from the developers and/or look stupid and incompetent if he or she makes an uninformed and/or unpleasant choice. I'm sure there are organisations where such decisions are made over golf games by non-technical people, but I've never done any work for one, and it sounds as dysfunctional as letting a committee of non-drivers choose your next car. But then again, that view may reflect the fact that I've mainly worked with relatively small companies that valued the opinions of their programmers, and for individual departments in large companies that were granted the flexibility to make language and platform decisions for themselves. In other words, this may come down to a difference in corporate culture, where DavidLiu works in one type of culture and EricHodges works in another.'' -- DaveVoorhis * I've worked in corporate cultures where tool sets were selected by engineering review boards. Those boards tended to have bright programmers on them, though, who actually used the tools they selected. Even there the programmers got to choose their tools, though. If they didn't want to use the selected tools they went someplace else. Programmers who had chosen those tools were hired to replace them. -- EH OK maybe this discussion is getting into HowToMakeToolChoices instead of the original, more light-hearted intent of sharing the viewpoint that there are MultipleArchitectureViews of OrganizationalPatterns related to the "JOB of SoftwareArchitect". If so, then please MoveItElsewhere (the discussion) and I will try to participate. -- dl ''You are welcome to move this discussion to any page you like. -- EH'' ---- '''CollaborationIsNotOnePersonDoingAllTheWork''' ''Who suggested it was?'' ok I created JavaBusinessIntegration, a topic very foreign to me. If with your extensive EJB knowledge you feel it does not have a future. Say so and quote references. If you think it is wrong, make corrections. If you think it is hopeless, rewrite it. I created that page not because I am compelled to tackle anything that come into the press, it is due to "unavoidable" professional interest in news and developments in ServiceOrientedArchitecture. ''This reply seems like a non sequitur. No one here suggested that collaboration was one person doing all the work. Why did you put that link here?'' To EH 1 of 3: Link to Coll... and/or JBI page? The "Collaboration..." link was put here because our esteemed XoYnKi creator does not seem to be much motivated in creating basic information for people wanting to know more about the JavaPlatform. And when he does take interest in a subject (e.g. his ears perk up when there is perceived blasphemy about CriticalItSurvivalSkills for SoftwareArchitect) he demands lots of timely interaction. My point is that: * To EH 1a of 3: If there is expectation that other people are to provide lots of information for viewpoints of interest to you, then you get want you want (clarifications, debates, ...) much easier if you had good track record of helping others. ''As I've explained before, Ward's wiki isn't a good place for creating basic information about technologies like the JavaPlatform. Sun provides excellent documentation for their product. As I've also explained before, I'm not here to research technologies for you. None of the above explains why you put that link on this page, as opposed to some other page. -- EH'' < * I respect your view on C2 not being a good place for XYZ (e.g. Java) even though I see things differently. Where I have more trouble is why "some Java experts" do not think it is necessary to "maintain relevance and quality" of "pre-existing" JavaPlatform pages, and "other experts" keep complaining about quality (again not fixing "pre-existing" pages), and their suggestion is to delete-delete-delete. I wonder whether "seasoned pros" here feel it is waste of their time to do chores (e.g. reversing spams, helping out new people) and only stay with their pet quality sandbox "high quality pages". Having said this, I do value your one sentence viewpoint on doing DistributedTransaction without use of EJB and I think other people value that opinion as well. -- dl * ''Who are you talking to? Are you talking to me? If so, it should be obvious that I don't think it is necessary (or even useful) to maintain pages about Java here. This isn't the place for them. There are other sites better suited to that sort of thing. And if you aren't talking to me, why are you saying these things to me? -- EH'' To EH 2 of 3: BTW the resonable I am spending time with you is that to me, people like yourself can provide "centre of excellence support" here on JtwoeeEnterpriseComputing. Others can be "local experts" on something else. And I should not have to be motivated to dig up material on J''''''avaBusinessIntegration because of new connections to SOA. It is very hard for me and I would rather have my time spent on something else. And minutes later I have found another example, this PotentialEnterpriseJavaBean page that was left without FixYourWiki attention, even though numerous Java gurus here find all the time they want on chats and launching insults. * ''No, you absolutely '''shouldn't''' have to be motivated to google all day long in order to pollute wiki with BigBallOfLinks. You should take a break, instead. How can we convince you that it would be a good idea ? What part of LarrySanger'''''''s words on the top of LarrySangerAndLessonsInCollaboration did you not understand ? '' * David, why not share your ''actual'' expertise with us? I think that would be vastly more interesting and useful than your latest discoveries as you meander through topics that appear not to interest anyone, including you. -- DaveVoorhis ''DL: I am not here to "provide centre of excellence support". I don't fill in the page stubs you create with technical details because most of them are just marketing hype that I have no interest in. Wiki is not your research department. -- EH'' to EH 3 of 3: At this moment I have taken TheCostinChallenge and requested him (a few times) to tackle and improve pages using DisagreeByAdding mechanism. He does criticises many people here, and it is painful to see his energy wasted on negative contributions. Given his SoftwareArchitect and EJB claim of knowledge he could have improved content on SOA to the benefit of all. If and when he does take up the challenge, I may be able to show him his own gaps of knowledge in WhatIsSoa, or learn from him instead. At this moment the WhatIsSoa remain technically flawed as a summary. I chose SOA because it is important, it is not a Microsoft monopoly. When we have better replacement, then we can clean up all the other "messy SOA stuff" lying around. Is that not better instead? -- DavidLiu * ''Is this flamebait or what ? If you really want me to tackle and improve such pages, just give me permission to do so, then with your permission I shall erase 90% of the buzz contributed as MicrosoftSlave, and it'll be a great improvement. But of course, you'd protest and given the current wiki technology you can rant and ramble all day long because the costs of the noise pollution are bore part of the TragedyOfTheCommons. But don't hold your breath until you'll get a debate with me, because it seems to me that we do not speak the same language. --CostinCozianu'' * David, you persist in claiming that WhatIsSoa is technically flawed. I've asked you several times to indicate how or why you feel it is flawed. Please do so, and stop trying to involve CostinCozianu in order to make what appears to be some sort of point that is entirely unrelated to the subject or the content of the page. -- DaveVoorhis ---- "Unfortunately with WikiTechnology here anyone can respond, and therefore the page is getting more messy than it necessary." If you don't want anyone to respond, don't use wiki. That isn't an "unfortunate" aspect of wiki technology, it's the key principle. -- EH ''You are right. So I will remember this page as a WorkInProgress and hopefully we can have a better sharing of views on '''What is P''''''rogrammingInTheLarge'''.'' ---- OctoberZeroFive CategoryRant