- ~ Posted by Deepak Kamboj on February 24, 2010
What is a Solution Architect?
The essence of the Solution Architect (SA) role is the conversion of the requirements into an architecture and design that will become the blueprint for the solution being created. This conversion is based largely upon the previous design patterns that the SA has been involved with in the past through reading and staying abreast of the latest techniques, or through personal experience.
It is this conversion part of the role - the role of the SA -that most often is underestimated in its complexity. Just as the ability of the Functional Analyst to create a requirements document is one part science and wrote procedure so is the creation of the architecture. The rest, however, is an art form. Creating effective architectures to create a solution requires the careful balance of dozens of development concepts ranging from "Keep it Simple Stupid" to "Fail to Safe".
In the process of converting requirements to an architecture there are often parts of the SA's role which seem out of place. For instance, there is often a fair amount of research that happens during this phase. The research may be targeted at testing a technology that will become critical to the architecture. For instance, the SA may test to see if USB or serial port access is available from Java if there's a need to read a device without downloading software. This process can either be done alone or depending upon the size and velocity of the project can be delegated to a development lead.
In addition to research on technologies and approaches critical to the architecture, there is often a review of patterns that might be useful to the architecture. Patterns are previously described and validated approaches that can be used to create portions of the solution. Patterns are released through research and can come from places such as Microsoft's software development libraries. Reviewing the pattern allows the architect to refresh their memory on the details of the pattern and to evaluate what additional guidance they will have to provide if they choose to use the pattern.
The final component to the role of solution architect is the motivation and guidance of the development leads. Development leaders need to buy into and accept the architecture, to know how the pieces will fit together at a high level. They must also see the art portion of the architecture to get an appreciation of the subtle nuances of their portion of the architecture. It's the art portion of the architecture that makes it elegant. That elegance helps to maintain cohesion between various parts of the design and encourages simplicity. It is necessary for the lower level design and approach to match the higher-level architecture for the solution to be cohesive. Once the development leader has internalized their portion of the architecture the SA must continuously motivate and reinforce the good work that is being done. They must continue to motivate the Developer Lead(s) to push through tough issues and create the solution.
Getting Started as a Solution Architect
For most people becoming the SA on a large project doesn't just happen. It's not like winning the lottery where one day your name is drawn out of the proverbial hat. It is, instead, a slow steady progression of learning and developing. A person may find their way to this coveted role within only a few years of professional experience but more frequently it takes a dozen or more years to consistently find themselves in this role.
The starting point is generally being the only person on a very small, and sometimes insignificant project. The project may be small enough that a single person may fill every role - including the role of solution architect. These little projects can even be ones where the organization hasn't identified the project as something that needs to be done yet but are items that a member of the software development team realizes that would be helpful.
Another approach to becoming a SA is to become a distinguished Development Lead (DL). The SA role and the role of the DL are very similar in the skill sets needed. The SA skill set is slightly broader and requires a bit more finesse, however, fundamentally the same. The SA lays out the architecture for the overall solution whereas the DL converts that architecture into detailed design. One approach to getting started as a SA is to become a DL and work towards the additional skills that a SA possesses. Most SAs have that ability to give some of their work to DLs looking to step up.
One of the ways to demonstrate an interest in the SA role, no matter what role you may currently be filling is to invest time in learning patterns. Because patterns form the basic building blocks of nearly every architecture, learning patterns makes it far easier to identify where they can be helpful. Also, reading books and articles on different architecture perspectives and new development techniques can broaden your point of view and allow you to see opportunities to create your own small sections of the solution.
The distinction between a development lead and the SA are often subtle. Where the development lead focuses on detailed knowledge of a particular area the SA is very broad. This allows the SA to view the problem from a different perspective. Instead of getting mired down into the details of implementing one specific thing the SA focuses on integrating various parts of the solution into one cohesive network that solves the larger problem.
The other subtle change is in accountability. While the development lead is responsible for their part of the solution, the SA is the proverbial one neck to choke if it doesn't all come together right. The SA has the ultimate responsibility for making the technologies work together. As a result the SA role comes with a requisite level of responsibility for the success of the project.
What's in their Toolbox?
The toolbox of a SA has more tools in it than most other roles. Most SAs have grown up in the software development world and have learned dozens of tools designed to help them be more productive.
Perhaps the most important tool in the toolbox is a visual documentation language, such as UML. The UML structure for describing a variety of different views of the software development problem in pictorial form is the most recognizable visual documentation language for developers. The SA should be familiar with each of the various UML forms and have expertise in the development of use cases, class diagrams, and occasionally state diagrams as well. Mastery of UML allows quicker, easier, and better communication with the DLs and the developers.
In addition to UML, the SA may need to be good at database design. Because most of the time the way that data is stored and retrieved is integral to the success of the solution, knowing how to design a database to hold the information is a critical part of the solution being successful. SAs know how to create databases and optimize them for good performance.
In addition to mastery of UML and database design, it's sometimes necessary for the SA to have experience with specific tools and processes when the organization has decided upon a specific process for software development. The most common software and process is the Rational Rose Unified Process. Other tools and processes exist the ones that the SA will have to master are based on what the organization has chosen.
Perhaps the most critical skills for the SA are the ability to create consensus and understanding around the architecture. While a development lead my need to involve a few people in their detailed design the architecture of the application touches every member of the team and there's a need to get them to understand it and agree with it. Once the SA has created the architecture it's time to communicate and sell it.
Where's the position heading anyway?
There is a great deal of pressure in the US to move development to countries with cheaper labor. While the SA role could be outsourced, , there is some insulation because of the need to work closely with the Functional Analysts in the gathering and organization of requirements. The distributed software of the global world requires more effort on the part of the SA and increases their need.
The overall need for SAs will continue to increase as the problems that the SMEs present are more complex and thus they require more complex solutions. The more complex the solution, the more SAs will be required to create it.
The software development tools were supposed to reduce the effort of the SAs and therefore reduce their need for the role, however, that increase in efficiency has been far outstripped by new demand.
The Good, the Bad, and the Ugly
- Good: Key, High-Value Position - The SA is a key role and one which can provide immense value if done correctly. This generally means a healthy salary.
- Good: An SA is likely to get to interact with many of the key members of the development team as well as key members of the user community. This makes it a very visible position.
- Bad: Hard to keep up - Being a SA means keeping up to date on a wide variety of new techniques, patterns, and tools. The effort to keep up can be very draining at times.
- Bad: Difficult to get right - The role requires balancing so many factors that it's difficult to get right. In other words, it's easy to fail.
- Ugly: Requirements - Although a good Functional Analyst can provide great requirements a moderately skilled one may not. The difficulty is that most people, including seasoned SAs, have trouble spotting bad requirements documents before it's too late. The SA must always have to consider that the requirements may require the SA to do a lot more research and legwork into what the client really needs.
- Ugly: If a project fails, the SA is at the top of the list for people to blame.
Conclusion
The solution architect role may be the most sought after role in the software development process but it's not without its challenges. Learning the broad array of skills, shouldering the responsibility, and dealing with the consequences can be more than the average mortal may want to take on.
About the Author
Robert Bogue, MCSE (NT4/W2K), MCSA:Security, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert's more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. He was honored to become a Microsoft MVP for Microsoft Windows Server - Networking. You can reach Robert at Robert.Bogue@CroweChizek.com
Backtrack: http://www.developer.com/mgmt/article.php/3504496/Anatomy-of-a-Software-Development-Role-Solution-Architect.htm
- ~ Posted by Deepak Kamboj on January 26, 2010
Software development is done differently at every organization, and in every home office throughout the world. The process that one organization or person uses to develop software may work for their specific environment and situation but may fail miserably in another set of circumstances.
It is, in part, the differences in environments which make it so difficult to quantify the process of software development in a single set of terms that all practitioners can agree to. As newer approaches appear on the scene, such as extreme programming and agile development the perspective of the world on what the process should look like changes slightly or dramatically.
However, despite these changes there are some things that remain the same. There will always be a need to understand the business problem, convert that problem into an architecture, convert the architecture into a solution, test the solution, and deploy the solution. Although each of these processes may change to some extent based on the programming models and tools being used, fundamentally there are some roles, which every process has in one form or another. One person may be filling all the roles or a handful of the roles, or one very specific role. Despite this there is a need for all of the roles - each serves a purpose. The origanization chart below gives you an idea of how each position fits together within an organization.
Common Roles
There is a series of roles that exist in most software development processes. As mentioned above one team member may be filling many roles and some roles may be suppressed for a specific type of project but all of these roles exist in one form or another in every software development project:
Click here for a larger image.
- Subject Matter Experts (SMEs) - The subject matter expert is the person or persons from which requirements are captured. These are the people who know what the software needs to do and how the process works. The SME role is somewhat different from the other roles because it is constantly changing as new clients (internal or external) are brought in to help design a solution. SMEs are rarely from IT - except when the solution is being designed to support IT. SMEs are most frequently the person who will receive the benefit of the system.
- Functional Analysts (FAs) - Functional analysts have the unenviable roles of eliciting clear, concise, non-conflicting requirements from the Subject Matter Experts who may or may not understand how technology can be used to transform the business processes in a positive way.
- Solutions Architect (SA) - The technical architect is responsible for transforming the requirements created by the Functional Analysts into a set of architecture and design documents that can be used by the rest of the team to actually create the solution. The Solutions Architect is typically responsible for matching technologies to the problem being solved.
- Development Lead (DL) - The development lead's role is focused around providing more detail to the Solution Architect's architecture. This would include detailed program specifications creation. The Development Lead is also the first line of support for the developers who need help understanding a concept or working through a particularly thorny issue.
- Developer (Dev) - The heart and soul of the process, the developer actually writes the code that the Development Leads provided specifications for.
- Quality Assurance (QA) - The quality assurance role is an often thankless position that is designed to find bugs before they find their way to the end customers. Using a variety of techniques ranging from keying in data and playing with the system to formalized, automated testing scripts the Quality Assurance team is responsible for ensuring the quality of the solution and it's fit to the requirements gathered by the Functional Analyst. Sometimes the QA team is known by their less flattering name of testers.
- Deployment (Deploy) - The deployment role is the one which packages up all of the compiled code and configuration files and deploys it through the appropriate environments or on the appropriate systems. The deployment role is focused on getting the solution used. To that end the role may include automated software installation procedures or may be as simple as copying the files to the appropriate place and running them.
- Training - The training role is responsible for documentation for the system as well as any instructor or computer based training solutions, which are designed to help the users better understand how the system works and what they can do with it.
- Project Manager (PM) - The project manager is responsible for ensuring consistent reporting, risk mitigation, timeline, and cost control. The project manager role is a problem solver role. They try to resolve problems why they are small so that they can be handled more quickly and with less cost.
- Development Manager (DM) - The development manager is responsible for managing multiple priorities of conflicting projects. The Development Manager role is also an escalation for issues from the team, which it is unable to resolve internally.
Of course, each organization has it's own take on these roles; however, these are the roles you'll see most often in an organization doing development.
Over the course of the next few weeks, articles will be published that delve deeper into each of the above roles.
Critical Skills for Every Role
In the articles describing each role there is a section, much like this one, which is designed to support a bulleted list of items that are critical to the success of the role. During the creation of the series a common set of skills was identified that were essential business skills that professionals in nearly every role needed to consider during their career. Rather than repeat them within the individual articles describing each role, they have been brought together here so that you could consider the impact of these roles in whole no matter where you are in the software development process. The common skills to all roles are:
- Understanding Business - Although some roles are focused very specifically around certain aspects of understanding and converting business requirements, every role in the process should have an awareness and sensitivity to the business processes and needs which require technology in the first place. Without this technology may be implemented but it may not solve the real needs and will therefore be considered a failure.
- Broad Understanding - Although an understanding of software development is critical there are other areas where an understanding can be invaluable. For instance, understanding how computers work internally including memory, cache, hard drives, etc., can help you learn how to more appropriately conserve those resources. Similarly understanding networking can help in the development of applications, which are compatible or even friendly to the networks that they're working across. SMEs broad understanding of the industry can be invaluable in terms of creating solutions that fit both the organization and the industry. The QA team can benefit the project by a broad understanding by minimizing QA costs while improving testing coverage. In short, a broad understanding can help every role.
- Multiple Perspectives - The ability to approach solutions from multiple perspectives is critical to software development. Understanding how each person who is working on a problem views an issue - or how different customers will view the solution is important to be able to find the best solution based on all of the information. There are always multiple ways of viewing - and solving - a problem. The trick is to find the best one from the list of possible options. The larger the list of options (perspectives) the better the solution.
- People Skills - Also known as soft skills, the ability to interact with other people and to be a part of a team is essential to nearly every role in a software development project. The lower the overall people skills of the team the higher the likelihood that the project will end in some explosion.
- Lifelong Learning - Although some might argue that the perspective of being a life long learner is more of an attitude than a skill, it is a critical part of being in a high-change industry like IT in general and software development specifically. What is learned today will be obsolete tomorrow. The only way to stay ahead of the game is to approach life from the perspective of continuous learning. Each new experience is a new opportunity to learn and each new year brings with it the need for skills renewal.
In the next article, the first detailed review of a role in the series, we'll delve into the role of the SME in the process and what specific skills can make an SME stand out from the rest.
About the Author
Robert Bogue, MCSE (NT4/W2K), MCSA:Security, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert's more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. He was honored to become a Microsoft MVP for Microsoft Windows Server - Networking . You can reach Robert at Robert.Bogue@CroweChizek.com
Trackback: http://www.developer.com/print.php/3490871
- ~ Posted by Deepak Kamboj on September 30, 2009
Introduction
When commissioning a third party to perform some bespoke development or design work, they will typically quote on the basis of a fixed price, or 'time and materials'. Choosing between the two can have some implications; as can discarding one in favour of the other.
There may be some cost planning benefits attached to a fixed price project, while a time and materials approach can improve flexibility. However, the inverse is also true; a time and materials project might spiral out of control, while a fixed price project may be delivered incomplete.
Fixed Price
A fixed price contract is established on the basis of a single price, single service understanding. In other words, the contractor should undertake to deliver, for the price in the contract, the service that is set out by the client; respecting the timeframe and deliverables agreed upon.
There are, however, a few points worth noting. Firstly, the cheapest offer is not always the best option. This is especially true if there are no penalties for late delivery or missed milestones. Without such penalties, the contractor may fulfill the project in 'downtime' : time that is not assigned to any other project, resulting in late delivery and poor quality work.
The materials used will also contribute to the price and quality of the end result. Taking both into consideration and balancing the quality against the cost is necessary if each offer is to be placed on the same footing.
Often this will need a third party expert to review the offers; since the quotes will be for work likely to fall outside the competencies of the client. Even where the client understands the problem area, legal or professional advice can prove invaluable.
Time & Materials
By contrast, a time and materials project quote is established on a per unit basis; the client pays for x person days, and y units of materials, once the project is deemed complete. The flexibility comes in being able to decide when the project is complete, the risk is that the costs can quickly mount up.
Since the essence of the project cost will be in the time that is spent, the client needs to be sure that the definition of time is agreed upon. It should not, for example, include resource management tasks that are not related to the project in question.
Thus, reporting of time, and time management will play a large part in the quote and follow up of the project plan. It is usually good practice to indicate what portion of the time paid for is allocated to project management, just so that no resources are wasted.
The definition of materials is also slightly more difficult to quantify in IT terms. One might assume that if the work takes place away from the premises of the client, that the client might be expected to recompense the contractor for heat, light, and electricity costs. Again, this should be stated in the contract; and if the contractor does not require such compensation, then that should be stated too.
It is worth remembering that projects are often late and over budget in IT. This is not, however, an acceptable situation, and should not be accepted as an excuse for a project not to be completed. In signing a T&M contract, though, the client does accept a slightly increased risk that the cost of the project might eclipse the budget set aside for it.
Summary
In the final analysis, any choice boils down to trust, risk, price and quality; and this true for both fixed price and time and materials projects. Some projects lend themselves to a time and materials approach, especially when the scope is flexible, and others to a fixed price contract.
The skill is in choosing the right kind of contract, obtaining the best value for money, and then managing the project to completion. Often engaging a temporary third party to take on this role can bring substantial benefits, especially when done within a co-sourcing framework.
Backtrack: http://www.cosource.com.au/Software-Development/Choosing-between-Fixed-Price-and-Time--Materials_12.aspx