2011년 6월 22일 수요일 오후 2:11
I work for group that puts out in-house automated inspection systems, the software they run on, and a host of tools to go with them. For the last 10-15 years the code has been designed and worked on my a mish-mash of engineers, CS students fresh out of college and hobby programmers. We now have two "bases" of code for different sets of machines and more side tools than I can keep track of. We cannot sustain the path we are on in terms of support while being able to develop for new systems and changing conditions. The smallest changes to our code right now force major overhauls of other pieces to make it all work again.
I have been advocating to my manager now for about six months that we need to get an architect into our company (probably on contract because we wouldn't need one year round) to learn a little about our systems, applications and future needs and get us a design for our software and systems. When our developers are looking at needing to make large changes, we go back to an architect to make sure we aren't hosing up the design. It won't be cheap up front, but we would be able to make better use of our limited developer resources (2-3 programmers) going forward.
Is this something an architect would be able to do? Is going into a company and helping them fix their mess of in-house software something that people "specialize" in so we could look for someone who has done this before? What kinds of information do they need to have to do their job? If I'm way off base -- where should I be looking? I know I'm not qualified to do a large design nor do I have any interest in learning that side of things. I'm an engineer and would like to keep it that way!
Thank you for any assistance or advise!
2011년 6월 27일 월요일 오후 2:03
Need of an architect has always been debated, perticularly over last 4-5 Years. Here are my views about it:
1> You need Devil's advocate sometimes to get things on right track and not "We decided it's OK!"
2>Architect thinks(May be I should say Could/Would/Should) from a top level and then gets down into finer details about system. Let me iterate a little: He looks at the current system, how the system has evolved over past few years (For the said organization), how it should have been done (This view becomes easy once the system is in place and you look at it after few years as a third party person), what the original focus was and if the real goal has been/can be achieved, are there any trade-offs (Technical, physical etc), can some of the things be broken down into sub-systems to get a better indicator(Performance of the system, Maintenance, frequency of updates etc). Architecture is not about building 1 single app or 1 single system, adding some functionality to existing systems rather it's like making a Horse outside the Horse's Womb. (Horse it the only animal which doesn't have unwanted organs and can use all the lges in many different ways).
3>When a system is in use for a considerable system, the conflict is inevitable. Somebody would prefer the old & somebody will need a new system. A good architect "Mentors" all cush issues. He owns the systems and makes sue the handover is smooth, incuding all the future based needs. Most geerally you'll find Architects getting involved in day-to-day programming part and always keeping an eye on B&R pocess.
4> @ Is going into a company and helping them fix their :- Yes architects are supposed to do that.
5>@What kinds of information do they :-- Prefered way of choosing an architect is to look for someone who has done work in your area of expertise, businesswise, developmentwise and so on. Must to see factor is his adaptibilty to any systems. (Personally I work on something that I call, "From Concept to Call centre")
6>And finally,Architect need not have White hair, wrinkled face. He just needs to be enthusiastic and the team should feel safe in his presence.
Regards, Jayant Akolkar
2011년 7월 7일 목요일 오전 10:53
Very interesting question Stephen.It seems to me you're on the right track.
Please correct me if my understanding is wrong.
You have an existing software built over a period of time. So you have quite a mix of code. Are you proposing to rewrite the application or only tweak the architecture and standardize it so that any new enhancements/changes follows the standard?
For either of these, yes, an Architect would be the right person to approach.
You can expect the following from an architect:
1. Understand your business and your existing system and propose an architecture. You would need to see the tradeoffs and the effort involved in implementing the architecture. Depending on the work involved, he/she can propose if a rewrite would give you a better value or tweaking the existing architecture would be better.
2. Come up with the technology stack which will be used.
3. Look at all the non functional requirements like performance etc and see how the architecture would address those issues.
4. Come up with a set of standards and best practices for all developers to follow
5. Come up the plan as to how it can be implemented. This would include methodologies (like Agile), deliverables, no. of resources needed, how you plan to phase out the existing system etc.
From your end, it would also be good if you can get the proposed architecture validated.
Hope this helps.
- 답변으로 표시됨 S. R. McGuire 2011년 7월 7일 목요일 오후 12:35
2011년 7월 7일 목요일 오후 1:26
You are correct. We actually have two "bases" built over about 10 and 5 years each. Ideally, I want to see them combined. Our dev team has been gutted over the last few years with atrition and layoffs and we just can't support it all anymore. Realistically, I may have to settle for a more gradual approach of cleaning up each base, establishing standards and practices and moving towards a final architecture. We still have to produce systems in the mean time no matter how ugly the code underneath.
Thank you for your insight on the responsibilities of the architect, how they think and helping me understand what to look for in a good one!