Ask ten IT managers and you will get ten different definitions.  The problem is that this particular role is still being defined and not all companies view it equally.  To begin, let's look at the commonly used role titles of Enterprise Architect, Solution Architect, Software Architect, Database Architect, and Application Architect.  From the point of view of Durango IT, All of these titles perform core duties, which are either the same, highly overlapping, or marginally different, with the exception of the Enterprise Architect, especially in very large organizations.  An Enterprise Architect often works on more strategic IT initiatives than do the other Architect roles and covers infrastructure networks and hardware as well as software systems.  However, most of Durango IT's clients are either mid-sized companies or departments within a large organization and therefore, we defined all of these roles similarly, and as such, we will refer to IT Architect roles under the title of Software Solution Architect.  This is particularly relevant for our discussion as a Durango IT is almost always working on specific applications that have wide strategic implications.

Durango IT provides a Software Solution Architect each project who is a highly experienced cross-domain, cross-functional, cross-industry expert.  To be effective as a Software Solution Architect one must have experience on multiple Hardware and Software Environments and be comfortable with complex heterogeneous systems environments.  The Software Solution Architect from Durango IT Architects is a highly seasoned senior technocrat who has led multiple projects through the Software engineering process or Systems Development Life Cycle (SDLC), and has usually performed in a variety of different roles in that life cycle.

 The Software Architect has an uncanny ability to share and communicate ideas both verbally and in writing to executive staff, business sponsors, and technical resources in clear concise language.  A practitioner of software engineering and software engineering processes, the Software Solution Architect is the person who organizes the engineering effort of a project by working closely with programmer team leaders.  The Software Solution Architect is responsible for the the overall vision that underlies the projected solution and transforms that vision through a clear and concise design.  The Solution Architect becomes involved with a project at the time of inception and is involved in the the Functional Analysis (FA) and developing the initial requirements.  They then remain involved throughout the balance of the project, often, as the Project Manager in the same way many buiding Architect firms remain the construction project's Manager.

The Architect's role is to convert functional requirements into a technical architecture and design that will become the blueprint for the system being created.

Too often, "Architect" is a role fulfilled through internal promotion offered to the best developers in an effort to retain them and to offer clients the services of a Software Solution Architect. Unfortunately not many developers have the broad-based experience and skills that make them a good Software Solution Architect.  The Solution Architect who possess strong technical skills can easily lead a project to failure if they are weak in their understanding of business concepts, organizational skills, interpersonal communicative skills, and understanding of internal politics between business and IT departments.

The Software Solution Architect who is assigned to work with the business stakeholders, business analysts, and the engineering team should be the one whom best fits the client's business domain.  This is to assure consistency in the transformation of business requirements into technical specifications.

This process is just part of the Software Solution Architect's role, which is very often misunderstood and underestimated in its importance and complexity.  Just like in architecting a high-rise building, creating effective architectures to create a software solution requires the careful balance of dozens of engineering concepts and principals.  In the case of software architecture, concepts such as domain driven design and design patterns are essential parts of creating a proper solution.

The final component to the role of is the inspiration and guidance of the engineering team.  Engineering team leaders need to buy into and accept the architecture, in order to know how the pieces will fit together at a high level.

A Durango IT Architect conducts extensive research on the best technologies and engineering practices that result in the most cost effective, long lasting solution.  We conduct extensive research on both commercial and open-source offerings.  During this research effort, we might deploy, prototype, and test, the various technologies reviewed.  This adds up to delivering to our clients a solution that will provide a long-lasting, maintainable solution that meets, or exceeds, in the areas of performance, adaptability, and reliability.

What tools does a Software Solution Architect use?

A Software Solution Architect utilizes visual documentation languages, such as Unified Modeling Language (UML).   Visual depiction of systems provides a common medium for communication between business stakeholders and the engineering team.  It is our experience that the lack of good communications between these two groups is the number one cause for less than desired result, or even complete project failure.

The Software Solution Architect illustrates the transformation of business concepts into technical specifications with various visual modeling tools in the same way a building architect models a building.  This provides the business owners with an understanding for what will be built and the engineering team and understanding of how to build it.

Finally, a Durango IT Architect strives to create consensus and understanding around the architecture.  While an engineering team lead may 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 Software Solution Architect has created the architecture it's time to communicate and sell it.

Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471]

THE METAPHOR

From icons and onion domes to suprematerialism and the Stalin baroque, Russian art and architecture seems to many visitors to Russia to be a rather baffling array of exotic forms and alien sensibilities.  Without any sense of the rich tradition of Russian culture, an appreciation of the country's enormous artistic wealth becomes a game of historical anecdote--"the church where so-and-so took refuge from what's-his-name"--or a meaningless collection of esthetic baubles--"I like the blue domes the best."  In fact, Russian art and architecture are not nearly so difficult to understand as many people think, and knowing even a little bit about why they look the way they do and what they mean brings to life the culture and personality of the entire country.

How does Russian Architecture relate to Software Architecture?

In the same way that Russian Architecture can be confusing to many, so can software design.  The architecting of good software is an art that requires a combination of many unlikely partners, and diverse skills, in order to bring together a, excuse the cliche, masterpiece.

The is the artist that works with all of the various tools available, collaborates with colleagues and stakeholder from a wide array of disciples and roles, to truly understand what needs to be created.  And then, documents an eloquent, yet cost effective, solution to that domain's needs.

Revised: January 6, 2011

So, what is architecture? The IEEE has the articulate, official explanation above; however, in reading the various gurus on the subject, I've concluded through project experience, that the explanation that Ralph Johnson of the University of Illinois - a widely published and respected technologist - has the most acceptable one to me.

"In most successful software projects, the expert developers working on that project have a shared understanding of the system design.  This shared understanding is called 'architecture'.  This understanding includes how the system is divided into components and how the components interact through interfaces.  These components are usually composed of smaller components, but the architecture only includes the components and interfaces that are understood by all the developers."

I will add to this by suggesting that it is not only the components that the expert developers view as important, but also the components that the business stakeholders understand and view important as well.  This is consistent with Domain Driven Design since many components are outcomes of developing the "Ubiquitous Language".

Domain Driven Design (DDD) is the embodiment of the concepts and terms held within a particular business domain.  This approach to software engineering starts with the understanding of these concepts and terms in order to reduce their complexity into small chunks of understandable ideas.  This is done in a model and the model centers around the common concepts within the business domain.

A domain model should provide a minimum of the following benefits:

• A common model that is used between the business stakeholders, IT managers, Software Solution Architect, and software engineers, which is used to communicate the functional requirements, data model, and business processes.
• The model is extensible, easy to maintain, and adaptable as the iterative process of development progresses.
• It helps plan for reusability
• The model makes testing of the business logic easy and continuous.

One Team; One Language

Durango IT Architects believes in the development team and the business stakeholders sponsoring the project to use one language, beginning with the Software Solution Architect's initial discussions about the project to requirements gathers through the coding itself.  This is what it takes to avoid the common miscommunication of functional requirements to the developers.  Simply put, a team needs a language to discuss their process and design techniques.

Many software development projects are started from the perspective of the technology - what database, what language, what tools, etc, rather than from the perspective of the business user who will have to use the software.

Many projects typically result in a solution that is inflexible, difficult to maintain, and ultimately more costly.

To avoid these problems, the domain experts (business end-users and managers) and the Software Solution Architect have to continually collaborate to find ways of documenting their understanding of the domain.  They must explore their subject matter, find a common language - this is called the "ubiquitous" language, and reduce the domain into its simplest terms.  From there they can build an architecture for the system that is simple, efficient, an adaptable.

Model Driven Architecture (MDA)

Models are understandable, visual representations of complex business domains.

Once the common language has been established and ingrained into the conversation, each part of the domain can be modeled.

A Software Solution Architect documents these domain concepts, and resulting models, in the form of UML (Uniformed Modeling Language) diagrams.  The UML diagram is an ideal medium for modeling software solutions as it graphically portrays the underlying concepts the solution is based upon.  This graphical representation is easy to understand for both technical and non-technical parties involved with the project, and it acts as a dictionary for the common "ubiquitous" language.

Model Driven Architecture (MDA)is an essential partner to Domain Driven Design (DDD).  It allows the insights into the domain to filter through to all the business stakeholders, domain experts, and programmers, through their common "ubiquitous" language, through the code itself, and especially to the end user.

There are numerous reasons why you might want to outsource software development to offshore software development companies; however, there are also numerous pitfalls.  The primary motivation to outsource is to reduce costs; at least that is the belief.  The other reason is that your company does not have the internal human resources, or, the resources lack the particular skills that are required for a project, or a technology platform used.  However, it seems that cost is the overwhelming driving force.

You are a Highly Valued Client

When choosing an outsourcing company it is very common to go with the biggest names in the business.  There is comfort in knowing they have done it before and are probably the biggest because they have been successful at it, the "big blue syndrome".  However, this success is a double-edged sword that tends to affect many projects in unexpected ways.  Picking the wrong outsourcing company can cost your project many times more than the savings you originally hoped to gain. This cut occurs most harshly with small to mid-market companies who typically do not have the same sized budgets, long-standing relationship, or strategic importance with the outsourcing vendor, but it can happen to the largest of companies as well.  Simply put, you are placed at a lower priority.

What does being at a lower priority really mean? Is your project scheduled further down a queue? Is your project put on constant piece-meal effort while resources are diverted to higher priority tasks or projects? Both of these can cost your project in time and money; however, in most cases, what it really means is the vendor assigns programming talent that is least experienced and skilled to your project.  It means that you get the junior person who the company can have cut their teeth on with your project.  Frankly, you are less important than the fortune 100 client who might represent 10-25% of the vendor's revenue while you represent less than 0.1%.  You do the math.

A personal experience with this was a few years back when I was the Software Solution Architect on a project with a major US pharmacy company.  The project was developing a call-center application.  The consulting firm I worked for had 200 consultants working in the regional office in Chicago.  There were One hundred and eighty consultants (programmers, project managers, Software Solution Architects, etc) assigned at this one client's site.  That is 90% of that region's consultants allocated to one client.

Now it would be nice to believe that the other twenty consultants had the same experience and capabilities as the other one hundred and eighty; however, that is just naive.  The reality is that this client was so important; the consulting company took particular care in selecting staff for placement with this client.  The projects that the other twenty consultants worked on were much smaller and vastly less important.  The consulting company pulled resources from project at less important clients if the larger client added a new project or fell behind schedule ones.  You get the picture?

Although most vendors will claim to have their entire staff equally qualified, some of these companies have thousands of employees, and it is just simply impossible.  So do not believe the sales hype.

Now I have insinuated that this is a problem of the largest development outsourcing companies; however, it can be just as likely to occur in a smaller company, but for different reasons.  The primary reason for a smaller company to end up with the same junior programmers is due to the smaller development company's inability to pay as much, offer as great of career path, provide bonuses, or present the same prestige on a resume.  In developing countries, prestigious names on the resume are often more important than the actual work you did or skills employed.

What a project sponsor can do to help avoid this situation is to request the resumes and sample work of each team member assigned to the project.  Make sure that a qualified Software Solution Architect reviews this to determine if you have a properly qualified and skilled team to work on your project.  I recommend a Software Solution Architect perform this review, as many technical leads will only review coding style and syntax correctness.  The Software Solution Architect will evaluate the programmers understanding of development process, advanced object-oriented programming techniques, the use of design patterns to solve programming problems, and their familiarity with frameworks.

Furthermore, arrange with the vendor a means to communicate with each team member on an ongoing basis and, verify that each assigned programmer remains on the project.  Obtain a resume and sample work when a team member is replaced.

While gathering team member credentials and monitoring team composition might seem like a lot of extra work, the reality is that because you have asked the vendor for this information, it automatically puts them on notice encouraging them to provide resources that are more senior.

Offshore Development Methodology

Offshore development has different challenges to other development processes, particularly when the offshore team is, a contracted vendor.  Some of the issues include accountability, utilization, and project.  Many aspects of traditional agile software development methodologies do not address these issues, leading many companies to adopt more traditional development processes such as the "Waterfall" approach.  One methodology that attempts to address these shortcomings in offshore development is the Stride methodology.  Stride holds the agile characteristics of being relatively lightweight, iterative, and incremental.

The Scrum methodology influenced Stride.  Proponents contend that Stride has several advantages that make it better suited for offshore (dual-shore) projects.  Its advocates claim, with some strong evidence, that it combines the advantages of agile development with the structure necessary to manage remote teams.  Scrum has the disadvantage of requiring daily meetings, which are ideally conducted with Product Owner input.  This might be highly cumbersome for offshore development environments.

I have worked on numerous offshore projects and I believe that each organization, and possibly each project, must evaluate all of the common development process and customize the approach best suited for that company's environment, in-house resources, capabilities of offshore vendor, and experience level of the Software Solution Architect.  I do not believe there is a best development methodology that can be applied like a cookie cutter.  I also believe that a weakness in all of the methodologies is the manner in which the architect and programmers interact with one another.  Finally, I believe there has to be in-house control(someone working directly with the Product Owner frequently) of the process and the design of the system.

Control the Design and you Control the Code Quality

A compounding problem occurs with some of these outsourcing companies due to a lack of control over system design.  In the same way the outsourcing company might have assigned an overweighting of junior programmers to your project, they are likely to have also assigned a less experience Software Solution Architect.  More senior Software Solution Architects allocated to the highest valued clients.

For larger systems designed in America or Europe, there have always been software design engineers, more recently called solution architects, assigned to the project.  I will discuss this role later on, but for now simply know that these are technologists with specialized skills.  They know how to transform the business requirements into valid technical specifications and set the design and development standards for the project.

It is my experience in working with offshore teams for almost 10 years that there are not such people fulfilling these roles in many companies, and only recently have the major firms in the major offshore outsourcing companies began to fill these positions.

The problem is that there are just not enough qualified technologists to qualify as Software Solution Architects.  Therefore, these companies are simply promoting the senior most programmers into these roles.  Even if the business requirements are not complex, if the system developed touches multiple points within the company, inexperience architects can miss important opportunities for consolidation, integration, and improving client's business processes. These aspects of the role of Software Solution Architect bring a high level of "value-added" that most programmers lack skills in.  This ability requires significant experience with an understanding of how businesses function as well as a deep understanding for the technologies employed.

In many personal cases, I have come into projects at a point of difficulty within the project.  It has been common for me to see coding problems like, single Java classes having 5,000, even 10,000, LOC. This can only occur with programmers unskilled with object-oriented programming, which is the result of your project being too low of priority for the better programmers, a lack of standards, insufficient design specifications, or all the above.

In the above example, the consulting firm was a US based company. Onsite, the project had a small contingency of programmers from a Philippine outsourcing company but much of the core coding was done in the Philippines.  Prior to me joining the project, there was little to no design work conducted.  The business requirements went directly to a technical lead for coding in the Philippines.  The only person onsite that oversaw this was a business analyst and project manager.  There was no architect or software engineer, onsite qualified to design systems at the highest level properly and, create the related design artifacts.  What I observed was a lack of proper skills in the proper place and utilized at the proper stage of the development process.

This project, and the other nine projects worked on with this large client, also lacked development standards to assure quality.  There were no, or insufficient, software design documentation regarding the technology stack being employed.  No discussion regarding frameworks, APIs, coding standards, application crosscutting concerns.  There was no "ubiquitous language", as Eric Evans calls it in his book, "Domain Driven Design".  In this case, it was primarily a lack of understanding by the vendor of the importance the role of Software Solution Architect plays.

What design work that was being done was being done by the technical lead and the programmer a task was assigned to.  They would generate a simple class UML diagram that showed each "Value Object" class and any subclasses inheritance from it.  There was no documentation regarding other critical design issues such as modularization, composition, crosscutting concerns such as security and transaction management, object interactions, application layering, package structure, naming conventions, etc.  Each programmer was responsible for doing it the best way they saw fit.

Another major problem with many offshore companies is with the initial requirements gathering.  The reality is that software systems are only as good as their requirements and the transformation of those requirements into technical specifications and ultimately a valid design.

Outsourcing the requirements gathering and the designing of a system has been the cause of most failures and major problems I have seen in large enterprise systems, which I have been party to as an Architect.

The business analyst, project manager, and Software Solution Architect are the key roles in determining a project's success.  These people are the "gate-keepers" if you will.  They assure accuracy of specifications and standards.  They can provide the needed guidance over programming teams offshore, making sure what is produced is what was spec'd.

My recommendation is to keep the requirements gathering and design work either in-house or with a local company that you have a strong relationship with and/or good supervision over.

Don't Rush Standards

One of the major affects of a lack of strong architectural guidance is that design and development standards are either non-existent or difficult to adhere to at best.  We know many projects stray off schedule and are full of bugs.  This problem exacerbates when your project falls into the hands of lesser experienced programmers, technical leads, and project managers.

What occurs is programming is done in a hurry and in a perpetual "catch-up" mode of coding.  Design documentation is hastily written after the fact rather than prior to each task.  This leaves the programmer guessing at far too many concepts, or simply cannot remembering what they coded weeks or months ago.  Comments are all but void in the code leaving the next programmer clueless as to what the code does without spending a disproportionate amount of time studying something that should normally only need a quick glance.  Moreover, testing, well forget about unit testing.

My recommendation for balancing the need for software development process and coding standards with deadlines and resource constraints is to employ a variation of the agile development process .  This slightly varied approach involves a Software Solution Architect working in partnership with the programmers in the context of the "paired programming" practice espoused in Extreme Programming (XP) .  I call this "PROTECT" ( PROgrammer archiTECT).  Well, that's the best I could come up with using an online acronym creator.

"Paired programming" is a practice promoted within the Extreme Programming (XP) methodology, and XP is a derivative of Agile.  Pair programming is a controversial practice.  It involves having two programmers programming on the same piece of code at the same computer station.  This looks very inefficient if you are not familiar with this practice.

There are also issues about the effectiveness of this practice when the two programmers have very specialized skills.  By trading out one programmer with the architect and rotating the architect amongst the team of programmers, you eliminate this problem because the architect will have a high level, broad background in the various technologies while the programmer might have a specialized skill.  This blending of perspectives produces code that is much more intelligent.  In many cases, this code base becomes more reusable and maintainable.  This is because the architect helps the programmer discover areas of great utilization of the code, improve their coding technique, and utilize design patterns in effective ways to reduce complexity or redundancy.

In addition, I recommend extensive, frequent code reviews and test-first , coding.  Software Solution Architects should conduct the code reviews as they are best suited to compare code to design specs.  They make necessary changes to the design based on new discoveries from the actual coding, or make recommendations for revising code.

I am a proponent of a modified version of the XP version of Agile development and, principally due to what I view as important benefits like improved quality, less rework, better communication and better knowledge sharing within teams but I think the biggest reason pair programming works is because programmers work harder when on a team.

Proof of this for me began back in 1990 when I was embarking on a major self-funded project I hoped to bring to market.  I was not very familiar with the technology I chose for the project so I employed another programmer.  We spent hundreds of hours programming together and I can say the quality of design, quality of code, and speed in which we produced code was unparallel for me in previous projects.  It dramatically shorted my learning curve and together.  We worked through some very complex algorithms easily as the result of programming together.

Instead of doing this in a design session in some meeting room with a whiteboard, we did it right at the computer and wrote the code as the ideas flourished.  The energy and excitement from working through difficult problems together energized the both of us and together we wrote far more high-quality code than either of us would have done singularly.

I highly recommend modeling your system using the agile-based modeling approach with much more robustness than simple class hierarchies or sequences of method calls.  This is easily accomplished with the PROTECT approach.

With short development cycles, it is easier to keep up with producing adequate documentation without slowing the project down.  It is also far easier to discover issues with the design or the code with the Software Solution Architect and programmers going back and forth with the stakeholders on a frequent basis.  This not only saves time, it might actually save the project.

Conclusion

Companies adopt agile-based methodologies with the goal of reducing cost and delivery time.  Using a modified agile version I briefly describe above as PROTECT, companies can optimize an agile approach to work with managing offshore projects effectively.

Many companies have experienced problems due to poor priority positioning within the offshore vendor's commitments; development teams lacking the level of skills required for the project; inconsistent, lacking, or poorly followed standards; lack of control of the design process; and ineffective development methodologies.

These companies usually begin to recognize these issues too far into a project to make major changes; therefore, usually fall back to the recommendations of IEEE or similar traditional methodologies.  The result was a severe trade-off: successful cost reduction for a painful loss of flexibility.  Many companies found that when the inevitable changes in requirements occurred, any cost savings quickly disappeared.

The PROTECT methodology allows companies to apply standards and control measures while using an agile-based process, an ideal combination for offshore development projects.

However, companies have only recently adopted agile development methods and therefore, there is still much to learn.  I am sure the best practices will continue to evolve.  Companies well versed in a variety of agile methods can more readily adapt to the changing landscape.

See our outsourcing services