Algunos me preguntaron que era un arquitecto de software y cuál era la diferencia entre un lider de proyecto o jefe de desarrollo.
Pues bien, en mis palabras, un arquitecto de software es aquel que está involucrado con 1 o varios desarrollos de software, pero desde un punto de vista macro. Es decir, comenzando por los requisitos (funcionales y no funcionales) y hasta llegar a conocer el impacto que tendrá en el hardware del cliente.
El arquitecto de software tiene tres variables principales sobre cuales moverse: tiempo, satisfacción del cliente y, principalmente, costo de los desarrollos.
Una definición de arquitectura de software, según "El proceso unificado de desarrollo de software" de Jacobson-Grady-Rumbaugh, lo compara a la arquitectura en la construcción. La aquitectura de software es el conjunto de planos de un desarrollo de software. Planos con las características más importantes resaltadas dejando de lado los detalles. Caraterísticas como requisitos de los usuarios e inversores, plataforma (sistema operativo, harware, base de datos, protocolos de red), bloques de construcción reutilizables, condideraciones de implantación, sistemas heredados y requisitos no funcionales.
Finalmente, transcribo otra definición para arquitecto de software que puede ser encontrada en "
What Does it Mean to be a Software Architect? - Part III" by Rob Daigneau (
http://www.designpatternsfor.net/default.aspx?pid=75 ):... a very simple starting definition for an architect:
1. A person who designs software systems and advises in the design of such systems.
2. A person who designs and guides a plan or undertaking related to software systems design.
I must emphasize that this was only a starting point. The follow-up question to this definition might be, “What do we mean by design, guide, and plan?†In response to this question, here are a few things that the architect might provide guidance and plans for:
The Creation, Capture, and Management of Business Requirements.
- Software architects oftentimes play an integral role in the elicitation and organization of business requirements. The premise here is that the purpose of architecture is to ensure that the business needs are fulfilled, and the resulting architecture must be directly influenced by the business requirements. Architects should, at the very least, be well-informed concerning the scope of business requirements to be addressed, must understand how product features map back to business requirements and their associated benefits, and must also be kept up-to-date concerning the evolution of the functional specifications for the proposed software product.
- Project Management Plans.
- Software architects typically have a unique perspective on the factors that impact the project’s schedule, budget, risks, and required resources. These factors include aspects of the solution design (discussed in the following section), the true nature of the business requirements, and the most effective means to staff development efforts to build what is described in the solution architecture.
- Architecture Plans.
- This is the key concern of the architect. Here are some components of a typical architecture plan:
- The creation of a solution design intended to achieve the desired business requirements.
- The software design
- The evaluation and selection of various technologies used to achieve certain functional or technical requirements
- Trade-off decisions that affect software design or the selection of various technologies
- Application integration strategies
- Physical deployment strategies
- "Buy, Borrow, or Build" decisions
- Recommendations on product release strategies and versioning approaches.
- The design of logical environments, and the processes that govern the flow of software deliverables from one environment to the next. This also typically includes capacity planning requirements, and recommendations for the specific software and hardware to be used along with associated configurations for each logical environment.
- Strategies to ensure proper governance of IT assets.
- The definition of standards and guidelines for design, coding, unit-testing, and build processes for the project or the organization.
- The evaluation and selection of development related tools and technologies, and the definition of related processes.
- Data conversion requirements.
La diferencia entre un líder de proyecto y un arquitecto está en el foco: generalmente el líder de proyecto se concentra en resolver las cuestiones más específicas del 1 o más proyectos. El arquitecto tiene la visión global de los proyectos.
En cuanto a las diferencias entre un Jefe de Desarrollo y un arquitecto está en las competencias: mientras que un Jefe de Desarrollo se desempeña mucho mejor guiando procesos de desarrollos, el arquitecto se desempeña mejor gestionando los proyectos que se llevan a cabo y la tecnología donde deberá aplicarse.
Sobre el autor
Pablo Pizarro es un Ingeniero en Informática que se especializa en
aplicaciones web empresariales. Está radicado en Mendoza, Argentina. Su
objetivo profesional es "mejorar la competitividad de las organizaciones a
través de la integración de la información". Actualmente, trabaja en el
área de I+D de la consultora minera Rojas y Asociados. Antes, trabajó en el área
de tecnología de Tarjeta Nevada (tarjeta de crédito). Hoy en día, se encuentra
desarrollando un proyecto sobre aplicaciones empresariales junto a otros
profesionales. Puede ser contactado a través de su email:
pizarropablo@gmail.com.
About the author
Pablo Pizarro is an Engineer in Information Technology, which specializes in
enterprise web applications. He lives in Mendoza, Argentina. His professional
objective is "Enhance competitiveness of organizations through the integration
of the information". Actually, he works in I+D department in Rojas & Associates
mining consultancy. Prior, he worked in the area of Technology in Tarjeta
Nevada (credit card). Today, he is developing a project about enterprise
applications with other professionals. He can be contacted at
pizarropablo@gmail.com.
View Pablo Pizarro's profile
Entradas
