|
Well I have the title but consider myself a senior dev, I do the design of the app from the database structure through to the UI. I then code it to UAT and hand it over to the support team.
IMHO any seasoned LOB developer must be able to do this. An architect on the other hand probably does the design and then gets a code monkey to do the development while he moves on to the next project.
I also think an architect should be able to design across multiple, disparate systems and platforms, something I am incapable of doing.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: I do the design of the app from the database structure through to the UI.
So few devs know to do it this way -- which is a hybrid Domain Modeling start and works for most projects very well / far better process than 95% of the devs use.
Thanks for mentioning it.
|
|
|
|
|
newton.saber wrote: So few devs know to do it this way
Really? I've done development this way for a long time, just from experience, I assumed most people did it that way.
Actually, working on DB structure is the part of my job where I'm actually doing a bit of architecture, that's when everything has to be thought through. It's just mindless tedium after that. Show me your (sane) DB structure and I have a pretty good idea of how the entire system works, it's the first thing I want to see when working on a new system.
|
|
|
|
|
I believe the role of the Architect is to ensure the technical design of the product is 'correct'.
In order to do this they need to be technical (so they know the techniques that could be used, and can select the best ones for the circumstances)
they also need to understand the whole project - as such they need to be able to talk to the product owner(s) at a non-technical level in order to make decisions on the technologies to be used.
So it is the architect that should be making the decision on different technical aspects of the project - and ensuring they are adhered to and are consistent.
Like a building architect doesn't just look at how pretty the house is, but ensures that the tensile strength of the materials is sufficient for the location - that the glass in the windows is the right glass for the situation, the Software Architect will make sure that the MVVM framework used is the right one for the job - and is used correctly; that the third party controls selected are used consistently etc.
they are the one that stops the developers from using some new technique they just read about because it looks cool, and forces them to use tried and tested techniques.
They cramp our style, but ensure a technically consistent and stable product. - That's the value.
The skills are many; They need to be a competent developer, and constantly learning about new things (and prepared to listen to input from developers with suggestions about using different tools for the job). They need to be able to listen to product owners and translate their requirements into sensible solutions (so you don't end up with a 7 tier solution to a desktop app that displays the time in China, or a monolithic application that runs the entire international business.)
Can the value be measured?
That's tough - without an Architect solutions can be a mix of techniques, inconsistent and difficult to maintain - unless all the developers just agree and work the same way) but measuring what may have been compared to what is is always hard!
PooperPig - Coming Soon
|
|
|
|
|
I really hate how terms from construction bleed into software development. No! you aren't an "Architect". You aren't a "Design engineer".
I've been named an architect and I have to deal with it - In my views the "Architect" is responsible for the technical direction that the project is taking and must maintain a vision of the entire system and plan technical items accordingly so that you don't end up with a mess of unmaintainable spaghetti. He is also responsible for dealing with management and explaining design decisions to the bean counters and time planners. But most importantly, I think the architect must follow his or others design decisions in code, be extremely competent technically and up-to-date with all SW dev. trends(and bullshit) and have the domain knowledge needed for making competent technical decisions.
If the architect doesn't code, doesn't keep current on SW dev. practices(or even lacks knowledge on well establised practices), and only sits inside a UML tool then he most likely is producing negative value for the team.
Unfortunately, life isn't this simple or idealistic and there's loads of "architects" out there that should be taken out back and shot. But there's also loads of developers out there that do what a real architect would do for a project that simply aren't recognized. Oh and it doesn't matter what you think an architect should do, it's what management thinks that matters. 
|
|
|
|
|
Great points. Thanks for replying.
I especially agree with you on:
slack7219 wrote: If the architect doesn't code, doesn't keep current on SW dev. practices(or even lacks knowledge on well establised practices), and only sits inside a UML tool then he most likely is producing negative value for the team.
And definitely:
slack7219 wrote: Oh and it doesn't matter what you think an architect should do, it's what management thinks that matters.
|
|
|
|
|
The function of architects is to have stupid, unworkable ideas, which the carpenters will redesign on site to make them work.
It's pretty much the same in the programming world.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: function of architects is to have stupid, unworkable ideas,
I've worked under these people too and they definitely are not architects, no matter how many times it says it in their title.
|
|
|
|
|
Hi,
I have that title and role in my company, and it makes me cringe a little when I read some replies implying that architect work is "just producing diagrams and let developers do the real work".
Best way for me to answer the questions asked is to explain the role of the architects in my company I guess.
So, here are some of the things I'm expected to do (along with my fellow architects):
- knowing everything about all the technologies we use and the ones we could use: languages, frameworks, protocols, front end, back-end, cloud platforms, tools, etc. (note that it is 'expected' from us, personally I feel far from having all the knowledge others think I have or should have... And my learning is done on my free time, obviously...)
- having an equal knowledge about the business, for all the clients
- knowing all the technicalities of every project we operate
- dealing with the clients and partners for everything technical. Involves presentations, meetings, fake smiles, and often dying a little inside and refrain from facepalming
- when starting a new project, designing for the big picture, taking into account performances, reliability, security and using knowledge of all the projects to decide what we can or not reuse
- breaking down the design into chunks for developers. Each developer is given requirements to meet for her chunk, then must design her chunk herself, that we will then review, with maybe several iterations.
- managing development processes (source control, build, etc)
- managing developers' recruitment and growth. Architects are in charge of technical interviews, developers' initial training, performance assessment, task repartition, etc.
- ensuring code quality
- building teams you know you can trust enough to delegate as much as you can
- being responsible. As an architect, you make the overall technical decisions, and you tacitely approve the decisions of every people to whom you delegated, meaning you're accountable for everything that can go bad
- taking the heat when things break, even if not design-related. Identifying the causes. Converting the heat you've taken into proper advice for developers so that the errors will never be done again. That's a key point of the role: taking the stress, but avoid putting it back on the developers (there is already the project manager for that...)
- being able to quickly fix anything on any project
- coding some critical parts, some tools or some abstractions to facilitate developers' work
- suffering from impostor syndrom and stress, because that's a lot to take on, and you're never ready to deal with it, and damn your too young for that.
|
|
|
|
|
I can see that you are under a lot of pressure and your role as Architect seems to have a firm description where you work. It sounds as if you are filling the role of the true Arhitect that many of us understand / expect the role to be.
Small Epiphany
As I was reading your long list of responsibilities I was hit by an epiphany of sorts.
Many of us have suffered under "Architects" who have honestly been more in the role of Manager -- who played the role of King -- who sat back, shot out what s/he thought were Genius Designs and then became utterly unaproachable when the Genius Design could not be implemented in real code.
That's the problem many here have with Architect role. However, your role, to me, looks like the real role of Architect. Thanks so much for chiming in with your thoughts.
|
|
|
|
|
Its an abstraction level. When I wear that hat, I am designing at the metaphor level...
Trying to validate the actual (real) design concerns. Does this HAVE to support 1000 computers connecting, picking off work to do (as in queues), or is it really 1,000 humans selecting the next thing they are skilled enough to handle with specific resources at their ready.
In some cases, is 256ms delay between requests Obscene or acceptable.
Knowing how technologies tie together, work together, and blending it with the Business Requirements. Add in testability, provabilitiy and fault tolerance.
Finally, what Public APIs will we support for others to continue to connect into us, etc. etc. etc.
When I am done, like others have said, I should be able to present management with the salient points of the process, and confirm we have it right. And at the same time, I should be able to work with the developers to make sure they build what is expected, and it works as described...
|
|
|
|
|
Great input.
Kirk 10389821 wrote: When I am done, like others have said, I should be able to present management with the salient points of the process, and confirm we have it right. And at the same time, I should be able to work with the developers to make sure they build what is expected, and it works as described...
Agree 100%. A very good summary of what the Architect should really be doing.
Sounds like your company is doing things right.
|
|
|
|
|
I used to work with a guy who thought he was an architect, but he was really just a programmer who didn't do anything. He would actually bring up in meetings the fact that some people (architects) spent their time designing and didn't bother with the code; that's what he wanted to be but not what he was hired to be.
So he sat around and read books and kept other programmers from working by talking to them all day about interesting ideas that he'd never actually implement. When management lit a fire under him he'd pound out some code, but it would all just be prototyping with function stubs. He actually felt that implementing functionality was beneath him, as was maintaining/fixing his code. So basically someone had to come along behind him and finish his work, for which he would take credit but no responsibility.
He was one of the most knowledgeable programmers I've ever worked with, and also one of the most useless. Despite his knowledge his code was poorly thought out and sloppy. He saddled the company with half-baked, buggy, incomplete in-house systems that were architected out the wazoo with five levels of frameworks but couldn't actually do what they were supposed to do.
True architects are great, but spare me the wannabes.
|
|
|
|
|
Great input. I've experienced this same thing.
StatementTerminator wrote: He was one of the most knowledgeable programmers I've ever worked with, and also one of the most useless.
Great quote, because these people do tend to show up on many development projects. Often found at large companies where they and their code can hide out.
|
|
|
|
|
I think the "Architect" portion of the title is often misapplied.
I worked for several years as a systems engineer (computer based systems for HVAC automation) in the construction industry. "Architect" in that context is how I see "Architect", abstractly, in "software architect".
It means looking at more than code, object design, UI and workflow, etc. It means looking at hardware, power requirements, air conditioning, real estate/building rental, contracts, business processes, financing, project management, cost projections and estimating, labor management, software estimating (the real voodoo economics), and all the other aspects associated with the total life of the project.
Consider this example:
You are the software architect tasked with taking existing code (mostly VB6, some C++, some Java) in a product suite that is currently in production with existing customers who depend on it. There is existing cash flow to consider. There are existing enhancements and bug fixes in the pipeline to consider that, if not done to meet deadlines, affect contracts and cash flow, as well as the company's reputation. The marketing research team has made a very persuasive case that the company must, within 2 years, have its product suite providing some or all of its services on mobile devices (as appropriate for the functionality). Further, VB6 is a 32 bit language, and it is obsolete, no longer supported by Microsoft. Its compatibility with current Windows OSs is "iffy" at best, and questionable going forward in a market where you would need to support Windows, Android, iOS, and perhaps Windows Phone. Part of your challenge is to migrate completely off VB6 without negatively affecting existing contracts, maintaining the existing product, and meeting marketing's need for an updated and enhanced version that meets the market's needs on desktop, laptop, and mobile devices, and does so securely, with good performance.
To do all that requires a lot more than software engineering alone. An architect for a building has to broadly cover similar areas, and often draws on others' expertise to do so, but making his or her own decision because they understand how each disciplinary area works and interacts. A software architect should do no less.
|
|
|
|
|
Great reading and great points and you are the first I've noticed to mention $$$.
Your points make the importance of all the outside elements pushing in on a project and the necessity of making sound trade-offs on the decisions made.
At the end it isn't about the technology at all, it is about a business solution. However, as soon as I say that, people are going to think I'm saying you could just write everything in JavaScript, but I don't mean that either. I mean the most important thing is the business solution related to the bottom line. That's why the true architect has to know so much because:
1. it has to be economically feasible for the company
2. it has to keep the company secure,
3. it has to be easily maintainable so the company doesn't lose $$$ doing maintenance,
etc.
|
|
|
|
|
I agree, and thanks.
Of course, the ones who would think you are saying you could write everything in JavaScript are missing the $$$ point. When it comes to the technology considerations, you have to pick technology, including the languages involved, that provide the performance, reliability, and scalability in the end-user environment that keep the user using your product (cash flow to your company) and not another product (loss of cash flow to your company).
Loss of cash flow means folks don't get paid.
IMHO, software architects, at least this one, should keep his or her hands in coding to some degree in order to know what the technology holds. If nothing else, coding and testing new language features and testing capabilities to gauge usefulness and benefit. At least enough time to know whether or not something is worth having others spend time with it.
|
|
|
|
|
|
A software architect is a good programmer and thinks ahead how the parts interoperate, whether or not the system is extensible and has good judgement to predict performance.
A "software architect" which is not a good programmer is a disaster. One cannot have guts feeling about interoperability, extensability and performance without the skill to actually build the pieces. The grounding would be missing. While a manager can compensate not being a top-notch expert by using people skills, listening skills and listing to the best engineers, an architect cannot. Without the skills one makes a fool out of oneself when trying to tell professionals how to do their work. Well, the syntax details of a language might be the one thing which does not matter.
A good software developer can do or is in the process of learning to do software architecture. But mediocre software developers can still code an algorithm without understanding the bigger picture.
|
|
|
|
|
Thanks for your input. I totally agree with you on:
Chris Jacobi wrote: A "software architect" which is not a good programmer is a disaster.
Many of us have suffered under "Architects" who could not code their way out of a wet paper bag.
They create grand visions of Rainbow Unicorns which cannot be created in code and then we devs have to build code that creates the program anyway.
|
|
|
|
|
Mmmmmmm!
Are there any Software Architects here?
Software Architect?
Well, architects design things. We in the software industry are often compared to those in the building industry, but I think that the software industry is closer to the movie making industry, and the software architect more like the director (who might some times take a role and act!)
But what makes a Software Architect?
Firstly, a Software Architect must understand the full Software Development Life Cycle(SDLC) AND where in that cycle they operate.
Like a movie, each software application has a life cycle.
Like a movie, a software application can be used over and over by the end user.
Unlike a movie, a software application can be changed in it life cycle and continued to be used by an end user. (although there can be a Director's Cut)
To make that happen, players in the SLDC must understand their role as well as the SDLC.
So who are these players?
There are 5 major players and under each of them are teams of other players.
These are:
Project Manager:
Team of Sub-Project Managers
Scrum Master or some other project methodology champion.
Business Process Manager:
Team of Business Process technicians
Team of Business Analysts
Software Architects:
Software Team Leads
Teams of Senior Developers and Developers
Quality Assurance Manager:
Team of Testers
Team of Technical Writers
Enterprise Architect:
Change Control Team
Team of DBAs
Team of System Engineers
Support Manager
Team of software Support staff
So now the 5 major players are going have a virtual conversation for the life of the software application.
The initial build of the software application will be done in a project, then later it will be Supported and enhanced in patches.
The idea for the project will come from a customer, either internal to the organisation or external to the organisation.
The Business Process Manager( or members of she/his team) will determine if the idea is feasible for the organisation.
If it is, the Project Manager will form a project team.
The Project Manager will be interested in three things:
How long will it take?
How many resources(both human and non-human) will it take?
How much will it cost?
The Software Architect will need the other players to help answer these questions.
Although, the Software Architect won't be able to give a complete picture, she/he will be central to the decisions been made.
The Software Architect will need to ask the Business Process Manager questions like:
What processes and how many are needed (broad strokes first then more finer detail later)?
Will this application be for internal organisation users or an application used by external users?
How many transactions per minute(TPM)?
More than 50,000 TPM may require a separation of Web farm from Application farm.
This would mean an increase in hardware usage and a different Architecture for the application.
How many features are to be available as Services to external "users" or internal "users"?
Such questions will lead to the type of developers required and how many.
The Software Architect will need to ask the Enterprise Architect questions like:
Do we need a perimeter network(for secure external user activity) and if so, do we have one already built?
Do we have enough servers/desktops for Development Environment, System Test Environment, User Acceptance Test Environment, Stress Testing Environments?
Can we use internal servers or can we use a Cloud infrastructure?
Which database can be use and do we have DBAs to provision databases for the environments and support those databases?
Which Internet Web Server(IIS or Apache/Tomcat) can be used?
What security standards need to be adhered to?
What is the Change Control procedure?
Do we have support staff for the released product and to assist in testing?
Such questions will lead to the type of application that will be built.
The Quality Assurance Manager will want to ask the Software Architect questions such as:
How often will we get builds, daily, weekly etc?
How can we communicate the feature functionality between Dev and TEST teams?
How do we report issues?
How do we perform Stress Tests, Performance testing, regression testing after version updates etc?
Such questions will lead to the amount of time and effort the development team will need to spend on testing: QA
After answering all the above, Developers will want to ask the Software Architect questions such as:
What are the application's tiers/layers?
If this is a web application, which browsers( and base versions) are targeted and what tools are to be used e.g. AngularJS, requireJS, KnockoutJS
If not a web application, which client front-end framework is to be used?
What Server language will be used?
Is it a Server pages or Web API or services (WCF) or RestFUL or MVC or other combinations?
Are we to use a IoC/DI framework, if so which one?
Do we use Aspect Oriented Programming(AOP) for cost cutting concerns.
Are we using Test Driven Development, if so which Unit testing tools are to be used?
Are we using Model Driven or Behaviour Driven development, if so what do the models look like and how are the behaviours managed?
Are we going to use a database/code object-relational mapper(ORM), if so, which one and is it to be database first, model first or code first?
What is the standard for user security and what tools are to be used?
What Caching mechanism is to be used?
How is the solution to be laid out?, ie:
Different projects for web projects, Interfaces, Data Models, Services, Application Logic, DALs
Which source control framework is to be used?
What is the deployment tool?
Are we to use Continuous Integration and Continuous Deployment.
Now these are just some of the questions a Software Architect needs to address on a day to day basis.
The Software Architect must also be able to explain the architecture and convince others of the soundness of the decisions that have been taken.
The Software Architect must also be able to converse with the CEO, CIO and end users in terms that these stakeholders can understand.
Through this whole post I have not mention once that the Software Architect should code.
But I have a firm believe that good Software Architects used to be very good Senior Developers with decades of programming experience in a wide variety of industries in numerous organisations.
Good Software Architects will WANT to code, because they love it!
So to the question: Are there any Software Architects here?
If you answer all the above questions on a day to day basis and also do some coding that is used by programming teams, you can call yourself a software architect.
If your resume looks like this post, then chances are you are a software architect.
Although Oracle and Microsoft have certifications that have architect in their title and others that cover the coding techniques required to answer some of these questions, neither has a certification that directly covers the tasks of a software architect.
The universities in my country don't have a Diploma or Degree that covers the breath of what a software architect does, although they do have Masters Degrees that covers Project Management and Business Process Management.
This is strange really, since Software is at the heart of what I.T. does (else those computers would just use electricity), and is at the heart of an organisation's procedures.
So you won't find a qualified Software Architect with a certification in Software Architecture or a degree on Software Architecture.
Software Architects are made from their own application to building successful software applications and continuous self-learning (ie reading books, blogs and threads like this one).
As I said, they( and I ) just love it!
Kindest Regards
frazGJF
frazGJF
modified 27-Jan-15 21:00pm.
|
|
|
|
|
Thanks for your great input. You are right about the Architect needing to know a little (and a lot) about everything. That's why -- as you indicated -- the Architect must really enjoy tearing the business apart and re-assembling it from every angle.
Because all of the pieces are connected and the software solutions we create are really just automating the business, every piece is entwined with every other piece. It creates a lot of complexity.
That's probably a big part of why companies get so overwhelmed by the whole thing, often lose their focus and then fail on projects.
|
|
|
|
|
Companies get overwhelmed by the complexity, rather than lose focus.
They seem to lose focus when what is really happening is that they are searching for the next "guru" that will give them the "silver bullet" solution.
Managers need to be more educated as to what the SDLC is and what the impact is on building software in-house. Normally when companies build software in-house they have moved away from their core business activity into a realm that they really do not understand.
(I am not advocating outsourcing, but I am advocating educating senior managers)
|
|
|
|
|
frazGJF wrote: Managers need to be more educated as to what the SDLC is and what the impact is on building software in-house.
frazGJF wrote: Normally when companies build software in-house they have moved away from their core business activity
Those are both very good and valid points.
|
|
|
|
|
Good analyse with consistent arguments. I agree with you... up to "Good Software Architects will WANT have NOT to code, because they love it must find the best coders and must recognize their best solutions for the project which he defines with its best experiment!" So I agree for its huge culture! But it doesn't have to be a good Mason but just know what a Mason can do best and how to do it."
entia non sunt multiplicanda praeter necessitatem
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
