아키텍쳐 아키텍트 / [책정리] 아키텍트 이야기

아키텍트 이야기 책 정리

이 책에서 전달하려고 한 아키텍트의 업무는,

  고객은 물론이고 비지니스 관계자들과 의사소통을 하면서 무엇을 만들어내야 하는지 정확히 발굴하고,

  뛰어난 기술력으로 개발팀을 이끌며 소프트웨어에 책임감을 갖는것이다.

아키텍트의 역할은 프로젝트 초기에 집중, 초기가 중요

SW품질 부분에서 ISO9126 에 대한 내용이 간략히 있었습니다. 

   이를 계기로 좀 더 자세히 서핑을 해보았어요 ☞

킥오프때 개발자들에 대한 파악 ( 기술 등 )

AA ( Application Architect ) 관련 정리된 글 http://beyondj2ee.egloos.com/292838

아키텍쳐 설계서 목차, 구성  ( http://joeytanya.tistory.com/8 참조)

개발자가 납득할 수 없는 시스템은 비즈니스에도 문제가 된다.

  -> 나 역시 지금까지 경험상으론 거의 99% 이상의 확률. 아마 다른 분들도 여러차례 겪었을 듯...

비지니스적인 사고방식이 필요하다. 고객이나 기술기반 없는 결정권자를 고려한 대화, 제안이 필요하다.

  개발의 앞단계로 업무를 확장해보아라

• 기존시스템을 유지하면, 어떠한 점에서 문제 발생 위험이 있다 와 같은 접근하에 근거를 제공하는 것이 효과적이다.
• 그건 기술적으로 좋지 않아요~ 와 같은 접근은 아무 의미가 없다.

시스템 구축, 프로젝트의 네가지 제약조건에 기반한 기획이 필요하다

  비용, 기간, 범위, 품질 -> 4가지에 대해 변경가능한 범위 ( 예를 들어 납기 1개월 조정 ) 와 우선순위를 세팅한다

아키텍트에게 요구되는 역T자형 역량

1. SW설계
2. 프로그래밍
3. 개발방법론
4. 인프라구축
5. 명세수립
6. 테스트방법
7. 요구사항 정의
8. 품질관리......

아키텍트에게 필요한 비지니스 이해 수준

고객 비지니스중 유통, 금융 처럼 특정 분야에 집중하여 전문성을 쌓는 방식 --> PM, 요구분석 담당자에게 어울림

아키텍트는 고객의 업종, 업태에 대해 책, 웹사이트를 통해 기본적 개념을 이해하고,

같은 업종 회사들의 사례 파악 정도로 고객과 충분히 의사소통할 수 있으며,

실제 업무의 전문가와 업무를 수행해나가면서 실용적으로 더욱 이해해갈수 있다.

문서

문서의 목적은 의사소통이다.

대량의 문서는 구속이 될 뿐이다.

고객은 문서자체에 가치를 느끼고 대가를 지불하지는 않는다

유지보수를 계약해야하는 문서라면 비용이 뒤따른다른 것을 명심해라. 최소화하라.

반복참조되는 정보는 문서작성, 유지할 가치가 있다

설계 공유

짧은 미팅, 벽에 메모 붙이기 등을 황용.

메모나 화이트보드 내용을 디카로 찍은후 인쇄하여 벽에 부착

테스트

애자일 방식 개발의 경우 테스트 자동화가 필수다

 

 

 

Architect의 자질과 역할

http://www.javajigi.net/pages/viewpage.action?pageId=138346501

 

  아키텍트의 길

pdf : The_Way_of_Architect.pdf

 

아키텍쳐, 아키텍트 등에 대한 정리 입니다. 아키텍쳐 이야기 책의 내용도 많이 들어가있습니다.

 

◆ 아키텍쳐

무언가를 가능하게 만드는 기반 틀

 

◆ SW 아키텍쳐

비즈니스 목표를 달성할수 있도록~~~~~~~

 

간단히 얘기하면... 이렇게 설계하라, 이렇게 개발하라 라는 지침, 즉 설계 지침, 구현 방침이다.

 

좀 더 자세히 말하면... 비지니스 목표 달성 및 요구사항 만족을 위한

다양한 관점에서의 판단지침이 아키텍쳐라고 할 수 있다.

• 기능 명세 설계
• HW, NW 구성
• APP 설계, 구현

 

◆ 개발 프레임웍 : 아키텍쳐를 실행하기 위한 실체로서... ( 설계와 ) 구현으로 이루어져 있다고 볼 수 있다...

                      아키텍쳐를 지원하는, 지키도록 하는 장치라고 볼 수도 있다

 

◆ 구성, 관계                                                                                                                                    

구성요소

구성요소간의 관계

외부요소와의 관계

전체 구성

<- 표준잡기, 원칙, 통일성, 조화, 유연성, 성능, 기술

 

◆ 공통기능, 기능개발 지원

 

◆ SW 아키텍쳐와 시스템아키텍쳐간에는 상호 연관성이 잇다

 

◆ 아키텍트

사용자 지향적인 사고로 sw 기획하고, 전체적인 틀을 세울수 있는 사람

프레임웍 준비, 구현, 테스트

프로젝트 과정간의 기술이슈에 대한 해결방안 제시

 

◆ 아키텍트 업무

아키텍쳐 정의

활용가능토록 공통기능 구현, 교육

이슈해결

 

◆ 프로젝트 관리자(Project Manger, PM)의 역할과 비슷해 보이는데, 프로젝트 관리자는 프로젝트가 원활하게 수행되도록 하는 데 중점을 두는 반면, 아키텍트는 설계와 프레임워크 개발 등 프로젝트의 기술적인 핵심 부분을 담당하게 되는 역할이라고 할 수 있다.

 

◆ 안영희? 안영회? 블로그에서 /아키 와 같은식으로 검색하면 좀 나올듯..

 

---

◆ http://www.infoq.com/articles/brown-are-you-a-software-architect

---

 

◆ 프레임워크 이용의 장점, 단점

• 공통 재사용 -> 사용 많이 한다 -> 공통 신뢰도 높음
• Good 모듈 -> 컴포넌트화 -> 공통화
• 개발자 기술 고수준을 요구하지 않음. ( 프레임워크 이용만 잘하면)
• 프레임웍 자체가 제약이 될 수 있다. coverage 가 적다던가, 호환성, 확장성이 좋지 않다던가
• 개발자 능력향상이 제한될 수 있다

 

 

이 글은 스프링노트에서 작성되었습니다.