Define the differences between the architect and developer roles.
Architects, Engineers, and Developers
One of the most challenging and exciting responsibilities of the architect is to select building blocks for the e-business solution.
At the technical and operational levels, it must be clear that the solution is interoperable--in other words, that the components are integrated to produce the desired service. While the architect is responsible for the success of the design, the developer is responsible for building and delivering the working solution. Let us look more closely at the role of the developer.
The role of the developer
We want to emphasize that although the developer and architect work in partnership, the architect assumes responsibility for the success of the project throughout the development.
It is therefore critical that the architect identifies and addresses any potential development problems early on in the design stage. To do this, the architect must draw upon the expertise of the engineers and developers who will actually build
Identifying potential problems
As we have discussed, the architect must maintain a global perspective.
The architect is uniquely placed to see the broadest picture of the e-business design and related issues, and therefore is best positioned to identify potential problems.
Working with the developers
Not only is the architect responsible for proactively identifying any potential interactivity problems between technical and operational
components, the architect should also ensure that these problems are resolvable.
The architect should be involved in ongoing discussion with the engineering team.
It is critical to the success of the project that the engineers:
Believe any identified issues can be resolveds
Believe they are supported in facing these challenges
Are confident that they can resolve the issues that may come up
Securing developer buy-in
It is essential that the developer understands and believes in the vision of the design. If the developer understands and buys into the vision of the design, he or she is more likely to solve problems than to consider them obstacles.
For example, a developer may suddenly encounter an unforeseen file incompatibility.
If this issue was not identified in the design goals as a potential problem, this may turn out to be insurmountable hurdle that could eventually derail the project because of the time constraints involved with devising a workaround.
It cannot be overemphasized that developer buy-in to the design is critical.
Building to the architect's design
In summary, the developers ultimately take on the task of building to the architect's design.
Any experienced architect will concede that the investment of time with the developers to achieve their buy-in to the design and its viability is time well spent. This buy-in also ensures that when unforeseen problems are encountered, developers will understand the impact and be better able to quickly identify acceptable solutions themselves, thus ensuring the success of the project.
In the next lesson, we will discuss the history of e-business and its relevance today.