내가 볼 수있는 한 Solutions Architect 는 Applications Architect에 대한 다른 “마케팅”용어 일뿐 입니다. 맞습니까, 아니면 실제로 역할이 어떻게 다른가요? 그렇다면 어떻게?
그리고 예, 저는 StackOverflow와 Google에서 이것을 검색했습니다.
답변
2018 년 1 월 5 일 업데이트 -지난 9 년 동안이 주제에 대한 제 생각은 상당히 발전했습니다. 나는 대다수의 사람들보다 우리 업계의 최첨단에 조금 더 가까이 사는 경향이 있습니다 (확실히 많은 현명한 사람들만큼 경계를 넓 히지는 않지만). 저는 애플리케이션, 솔루션, 엔터프라이즈, 크고 작은 여러 회사에서 다양한 수준의 설계자로 일했습니다. 우리 기술 산업의 미래는 대부분 건축가가없는 미래 라는 결론에 도달했습니다 .. 이것이 당신에게 미친 것처럼 들리면 몇 년을 기다리면 당신의 회사가 따라 잡을 것입니다. 그렇지 않으면 당신의 경쟁자가 당신을 따라 잡을 것입니다. 근본적인 문제는 “아키텍처”가 애플리케이션 / 솔루션 / 포트폴리오에 대해 내려진 모든 결정의 합에 불과하다는 것입니다. 그래서 제목 “건축가”는 실제로 “결정하다”를 의미합니다. 즉, 무엇으로도 많이 말한다 하지 않습니다말하다. “빌더”가 아닙니다. 사람들에게 “구축”을 암시 적으로 말하는 경력 경로 / 계층을 만드는 것은 “결정”보다 낮으며 “결정”은 “구축”에 대한 직접적인 책임이 없습니다 (제목 차이로 인해). 아직 건축가 직위에 매달리고있는 사람들은 이것에 비 웃으며 “하지만 나는 실전입니다!” 당신이 단지 건축업자라면 의미없는 직함을 포기하고 다른 건축업자들과 구별되는 것을 그만두십시오. “모든 건축자는 결정자이고 모든 결정자는 건축 자”라고 강조하는 회사는 경쟁사보다 빠르게 움직일 것입니다. 우리는 모두에게 “엔지니어”라는 제목을 사용하고 “엔지니어”는 결정하고 구축하는 것을 의미합니다.
원래 답변 :
대규모 조직에서 일한 적이없는 사람 (또는 가지고 있지만 기능이 저하 된 조직)의 경우 “건축가”가 입에 나쁜 취향을 남겼을 수 있습니다. 그러나 이는 정당한 역할 일뿐만 아니라 현명한 기업에게 매우 전략적인 역할입니다.
-
애플리케이션이 너무 방대하고 복잡 해져서 전체적인 기술 비전과 계획을 처리하고 비즈니스 요구를 기술 전략으로 전환하는 것이 정규직이 될 때, 즉 애플리케이션 설계자가 됩니다. 애플리케이션 설계자는 종종 개발자를 멘토 및 / 또는 리드하며 책임있는 애플리케이션의 코드를 잘 알고 있습니다.
-
조직에 애플리케이션 및 인프라 상호 의존성이 너무 많아서 코드에 관여하지 않고 조정 및 전략을 보장하는 것이 풀 타임 작업 인 경우, 그것이 바로 솔루션 설계자 입니다. 솔루션 아키텍트는 때때로 애플리케이션 아키텍트와 유사 할 수 있지만 비즈니스를위한 논리적 솔루션을 구성하는 특히 대규모 애플리케이션 제품군에 걸쳐 있습니다.
-
조직이 너무 커져서 솔루션 설계자를위한 높은 수준의 계획을 조정하고 비즈니스 기술 전략의 조건을 구성하는 정규직이 될 때 그 역할은 엔터프라이즈 설계자가 됩니다. 엔터프라이즈 아키텍트는 일반적으로 경영진 수준에서 일하며 CxO 사무실과 지원 기능은 물론 비즈니스 전체에 자문을 제공합니다.
인프라 아키텍트, 정보 아키텍트 및 기타 몇 명도 있지만 총 수면에서 이들은 “빅 3″보다 적은 비율을 차지합니다.
참고 : 다른 많은 답변에서 이러한 제목에 대한 “표준이 없다”고 말했습니다. 그것은 사실이 아닙니다. Fortune 1000 대 기업의 IT 부서로 이동하면 이러한 타이틀이 일관되게 사용됩니다.
“건축가”에 대한 가장 일반적인 두 가지 오해 는 다음과 같습니다.
- 건축가는 단순히 멋진 직함을 가진 선배 / 고소득 개발자입니다.
- 건축가는 기술적으로 쓸모없고 몇 년 동안 코딩하지 않았지만 여전히 비즈니스에 무게를 쏟고있어 개발자의 삶을 어렵게 만드는 사람입니다.
이러한 오해는 많은 아키텍트가 매우 나쁜 일을하고 있고, 조직이 아키텍트가 무엇인지를 이해하는 데 끔찍한 일을했기 때문입니다. 최고 프로그래머를 아키텍트 역할로 승진시키는 것이 일반적이지만 그것은 옳지 않습니다. 일부 중복되지만 동일 하지는 않습니다 . 최고의 프로그래머는 종종 이상적인 설계자 일 수 있지만 항상 그런 것은 아닙니다. 훌륭한 설계자는 IT 산업 의 많은 기술적 측면을 잘 이해 하고 있습니다. 개발자가 필요로하는 것보다 비즈니스 요구와 전략에 대한 더 나은 이해 ; 뛰어난 의사 소통 능력그리고 종종 일부 프로젝트 관리 및 비즈니스 분석 기술. 건축가는 코드로 손을 더럽 히고 기술적으로 날카롭게 유지하는 것이 필수적입니다. 좋은 사람은 그렇습니다.
답변
기본적으로 IT 인증의 세계에서 “진정한”전문 조직의 발을 밟지 않는 한 원하는대로 자신을 부를 수 있습니다. 예를 들어 명함에 “Microsoft Certified Solution Engineer”가 될 수 있지만 “Professional Engineer”(또는 P. Eng)라는 마법의 문구를 쓰면 철제 반지가없는 한 법적 문제가됩니다. “실제”아키텍트에 대한 유사한 제목이 있다는 것을 알고 있지만 기억할 수는 없지만 “Cisco Certified Network Architect”또는 이와 유사한 사람이 될 수 있다는 것을 언급하지 않는 한.
답변
건축가 유형 간에는 유효한 차이점이 있습니다.
엔터프라이즈 아키텍트는 엔터프라이즈 전략과 밀접한 관련이있는 엔터프라이즈 솔루션을 찾습니다. 예를 들어 은행에서는 전체 IT 환경을 살펴볼 것입니다.
솔루션 설계자는 은행의 새로운 신용 카드 취득 시스템과 같은 특정 솔루션에 중점을 둡니다.
도메인 설계자는 특정 영역 (예 : 애플리케이션 설계자 또는 네트워크 설계자)에 중점을 둡니다.
테크니컬 아키텍트는 일반적으로 비즈니스 측면에 덜 집중하고 기술 측면에 더 집중하면서 솔루션 아키텍트 역할을합니다.
답변
아니요, 건축가는 프로그래머와 다른 직업을 가지고 있습니다. 설계자는 비 기능적 ( “능력”) 요구 사항에 더 관심이 있습니다. 신뢰성, 유지 보수성, 보안 등과 같은 것입니다. (동의하지 않는 경우이 사고 실험을 고려하십시오. 복잡한 웹 사이트를 수행하는 C로 작성된 CGI 프로그램과 Ruby on Rails 구현을 비교하십시오. 둘 다 동일한 기능 동작을 가지고 있습니다. RoR 아키텍처 를 선택하면 어떤 이점이 있습니다.)
일반적으로 “솔루션 아키텍트”는 “애플리케이션 아키텍트”가 고정 된 플랫폼 내에서 작업하는 전체 시스템 (하드웨어, 소프트웨어 등)에 관한 것이지만 용어가 그다지 엄격하거나 잘 표준화되어 있지는 않습니다.
답변
아키텍트 직책에 대한 산업 표준 정의는 없습니다. 애플리케이션 / 시스템 / 소프트웨어 / 솔루션 아키텍트는 모두 일반적으로 강력한 설계 및 리더십 기술을 갖춘 선임 개발자를 지칭합니다. 설계, 전략, 개발 (주로 핵심 서비스 또는 프레임 워크) 및 관리의 균형은 조직과 프로젝트에 따라 다릅니다.
저에게 정말로 다른 의미를 가진 유일한 “아키텍트”직함은 “엔터프라이즈 아키텍트”입니다. 저는 IT 전략 직책에 더 가깝다고 생각합니다.
답변
‘아키텍트’는 높은 수준에서 잘 작동하는 여러 계층의 애플리케이션을 설계 할 수있는 사람에게 부여되는 직함입니다. 특정 유형의 기술 (예 : “솔루션”, “응용 프로그램”, “비즈니스”등)없이 일반적인 유형의 ‘건축가’에 들어가는 것은 모두 마케팅의 말입니다.
답변
실제로 상당한 차이가 있습니다. 솔루션 설계자는 전체적으로 요구 사항을 봅니다. 예를 들어 요구 사항은 피자 주문을받는 콜 센터의 직원 수를 줄이는 것입니다. 솔루션 설계자는 올 필요가있는 모든 구성 요소를 검토합니다. 이를 충족하기 위해 사용할 음성 인식 소프트웨어, 필요한 하드웨어, 호스트에 가장 적합한 OS, 프로비저닝 시스템과 IVR 소프트웨어 통합 등을 함께 충족해야합니다.
반면에이 시나리오의 애플리케이션 아키텍처는 소프트웨어가 상호 작용하는 방식, 가장 적합한 언어, 기존 API를 가장 잘 사용하는 방법, 존재하지 않는 경우 API 생성 등에 대한 세부 사항을 다룹니다.
둘 다 각자의 위치가 있습니다. 요구 사항을 충족하기 위해 두 작업을 모두 수행해야하며 대규모 조직에서는 전담 인력이 있어야합니다. 소규모 개발 상점에서는 개발자가 모든 아키텍처 작업을 작업의 일부로 선택해야하는 경우가 많습니다. 전반적인 개발, 다른 사람이 없기 때문에 마케팅 용어라고 말하는 것은 지나치게 냉소적이며 실제 역할 (개발자가 임시로 선택하더라도)이며 특히 프로젝트 시작시 가치가 있습니다. .
