Skip to main content

Software Architect vs Project Manager

Most of the organizations expect the technical role needs to play / assist team by project manager.

The project manger has to be good in technical concepts to design the application and helping the team on problem solving.

Based on my experience, in this article I have presented the important points to be focused during designing the application by project manager who is expected to play a role of an architect or work with architect:

1) Understanding end to end development life cycle:

Refer the below end to end development life cycle, the architecture stared during the requirement and matured during development.

During the requirement gathering phase the architect need to concentrate on feasibility of implementing the functional and non functional requirement. 

Need to on board few resources in to project to perform the POC for evaluating the initial design.

Create the design of the application during elaboration phase; the main point here is to create right size architecture base on project cost, schedule and scope.

2) Understand what architect does:

The architect role is limited and need to play a role within the provided constraints. The constraints are Available Software, Hardware, Infrastructure and organization process.

3) Architects manage risks and changes:

The architect needs to develop the design that has layers of components and loosely coupled (for example use the microservices).

Identify the risks expected in the project and provide the flexibility to change the design during the development phase.

The changes might be coming from business that requires changes in the architecture; the architecture should be flexible to accommodate the changes.

4) Architects communicate with stakeholders

Architect needs to communicate with stakeholders on the approach, assumptions made and support from client and organization for getting the resource and infrastructure.

Architect prepares the Software architecture document, share with the stakeholders and get the sign off from client.

5) Architects build the reusable components:

The reusability provides fewer problems, greater productivity and easier maintenance.  Architect needs to build to reusable components by refine existing components that have been used in other systems.

6) Architects influence the requirement:

Architects working in constrains like functional and non functional requirements, Resource, Schedule, Cost and Real time qualities. He needs to influence to requirement to get Maintainability, Scalability of the application in the real environment.

7) Derive the solution from business needs:

The architecture needs to support the boundary between the system and the system outside which interacts such as end user and external system. The system need to support business workflows, rules and satisfy the functional requirements.

8) Architect refines the solution based on the Technology:

The architect need to refine the solution based on the technology, for example if you are working for automobile or finance organization and they have working on Oracle SOA suit for enterprise solutions, need to make the solution based on the technology available in the client place.

Need to develop the solution using web services to make smart integration with other systems.

The conclusion is design the simple architecture which has multiple layers instead of complex architecture. 

The architecture needs be flexible to accommodate the changes and supports painless to integrate with external systems.

Comments

Post a Comment

Popular posts from this blog

Certified Enterprise Architect Professional (CEAP) - Module 4 - Architecture Precursors

 Architecture Precursors: Precursors to modern Enterprise Architecture (EA) include early frameworks like IBM's Business Systems Planning (BSP), which focused on aligning business strategy with information systems, as well as other Information Systems (IS) architecture methodologies that emerged in the 1970s and 80s, emphasizing the connection between business processes and IT systems, laying the groundwork for the holistic view of an organization that EA represents today; the "Master Plan for Information Systems" by Evans and Hague is also considered a foundational concept in this area. Drivers: internal / external pressure enforce to change the system Aims & Directives: Aims:  Goals Objectives Requirements Directives: Principles (example: Principles can be associated with business, data, applications, infrastructure, or security) Policies (example: Members of the public have minimal access to data) Business Rules (example: A rule directs and restricts a procedure)
Post a Comment
Read more

Scaled Agile Framework (SAFe)

The Scaled Agile Framework (SAFe) is a set of organizational and workflow patterns for implementing agile practices at an enterprise scale. The framework is a body of knowledge that includes structured guidance on roles and responsibilities, how to plan and manage the work, and values to uphold. Scrum is a simple, flexible approach to adopting Agile that's great for small teams. SAFe is an enterprise-wide Agile framework designed to help bring Agile beyond the team and into the company as a whole. Scaled Agile has built a comprehensive level that includes all the four layers called the team, program, large solutions, and portfolio level. 4 Layers: Portfolio - Strategy, Vision, Roadmap, Strategy goal, Decision making, Budget, Portfolio level metrics,  Program - Align multiple teams towards a common mission, Bring together all the Agile teams, transparency, collaboration, and synchronisation, Scrum of Scrums, Product Owners to define the overall vision. Large Solutions - ar...
Post a Comment
Read more

4 T's - Technology, Time, Teamwork, Transparency

 1) Technology: Software development technologies are the tools and methods that developers use to design, develop, test, and deploy software applications. These include a wide range of software technologies, such as programming languages, frameworks and libraries, databases, and cloud computing platforms. 2) Time: A timebox is a fixed time period within which a deliverable must be produced in a project management context. It's a time management technique that involves dividing time into individual time periods, each with its own goal, duration, and deadline. Timeboxes are self-contained calendar events that can't be extended once they've started. The fundamental principle of timeboxing is that time in timeboxes can't shift, and once the time runs out, work must stop, even if the task isn't finished.  3) Teamwork: Teamwork in project management is a measure of how well a project's team works together to achieve a goal. It involves collaboration, communication, a...
Post a Comment
Read more