A Technical Architect of software applications needs to be business-aware as well as technology-aware. An architect is usually called in to advise management on how to reengineer an existing system and take it to production, or to define requirements for a new system. An architect may also be tasked with developing a project plan which might include recommendations for training and mentoring customer's technical and operational staff.
Technical Architects (also known as Software Architects) are involved in all stages of business systems development lifecycles, although they typically are not doing the actual coding of the various applications. Their main focus is on the overall architecture and ensuring that service-level requirements (QoS) are being met.
Technical Architects are responsible for defining and writing implementation strategies and methodologies. This knowledge is necessary to ensure project success. Application architecture decisions revolve around quality-of-service (QoS) requirements, also referred to as non-technical requirements, testing, exception handling, distributed processing, legacy system integration, and ensuring the proper development of business components and service-mapping to business requirements.
Also, one of the main responsibilities of the Architect is to identify and evaluate third-party software that may be required for the development process of the creation of the business components.
Another significant responsibility of the Architect is to mentor developers and guide their software design process. This is an important task as it relates to the timeframe of project deliverables and the overall quality of software deliveries. The Architect should ensure that a comprehensive documentation system is in place to support effective group communication and ease the transitions of adding new developers to the project and the future development of the application.
A third responsibility of the Architect is to keep project managers informed about changes in scope and/or requirements. If there are significant changes or additions to business requirements, they should be documented in use cases and presented to the business side for future releases. After the initial use cases have been written, the Architect should work on estimating project size and effort.
Business requirements are the features that a software application must contain, and are described in business terms using use-case narratives. These may optionally be used to create Use Case diagrams if conditions exist to warrant their use. More emphasis should be place the initial prototype implementation which is based on business-like descriptions contained in the use cases. It is important to refrain from including pre-mature technical design decisions.
Use cases should be written in business terms are could be used as a "contract" as to what we be created and delivered.
An application's business requirements would consist of what the application does or what it is used for. Examples would be (1) recording business expenses, (2) processing customer orders, (3) updating schedules.
Examples of an application's QoS requirements are system scalability, maintainability, manageability, performance, security, extensibility, etc.
Comments(0)