IT 아키텍처가 중요한 이유를 말씀 드리겠습니다. 그 이유를 말씀 드리겠습니다

우리는 그림 그리기를 좋아합니다 !!

(Miguel Angel Coll) (2020 년 7 월 2 일)

지난 5 년 동안 IT 아키텍처 기능을 다루는 경력에 투자했습니다. 그 세월 동안 나는 단지 건축 기능의 존재를 나 자신에게도 정당화해야했다. 때로는 우리가 실제로 일을하는 사람들 (개발자 및 시스템 운영)에 둘러싸여 침입자 인 것처럼 느끼기도합니다.

5 년 후에도 여전히 아키텍처가 중요하다는 확신을 가지고 있습니다. 증명해보세요.

가장 좋은 가치

IT 아키텍처에 대한 미션을 하나만 선택해야한다면이 미션을 선택하겠습니다. IT 부서와 플랫폼은 일반적으로 단지 성장하고 있습니다. 그들 중 일부는 회사가 성장하고 있기 때문이고 다른 일부는 회사가 디지털 혁신의 한 가운데 있기 때문입니다. 어쨌든 결과는 동일합니다. 해마다 더 많은 시스템, 더 많은 팀, 더 많은 복잡성이 있습니다.

저는 IT 플랫폼을 다음과 같이 지나치게 단순화하고 싶습니다.

주 아키텍처 기능은 IT 플랫폼 비용과 그것이 좋은 형태로 제공하는 가치.

얼마 전에 저는 API를 통한 온라인 상품 배포를 기반으로하는 비즈니스 모델을 가진 여행 회사에서 일했습니다. 이러한 API는 Oracle Exadata를 기반으로하는 거대한 단일체 시스템과 강력하게 결합되었습니다. 즉, API 트래픽이 증가하고 트래픽이 전환율보다 더 많이 증가 할 때마다 데이터베이스를 수직 확장해야합니다.

아키텍처가 IT 플랫폼 효율성을 촉진합니다.

아키텍처 제안은 API 서비스를 분리하여 새로운 마이크로 서비스 레이어를 생성하는 것이 었습니다. 클라우드는 예약 및 운영을 위해 데이터베이스 인프라를 유지하면서 저렴한 비용으로 모든 트래픽을 처리합니다 (불행히도 기하 급수적으로 증가하지 않음). 그 결과 다음 해에 DB에 더 이상 새로운 인프라가 필요하지 않았고 트래픽과 IT 비용 간의 관계가 개선되었습니다.

동일한 언어 사용

걱정하지 마십시오. 프로그래밍 언어 (자바, 파이썬 등)에 대해 이야기하지 않습니다. 건축가로서 저는 약간의 통제 (혼돈 아님)를 가지고 다양성을 위해 개방적입니다. 여기서는 Frederick P의 Mythical Man Month 및 소프트웨어 엔지니어링에 대한 기타 에세이 에서 처음 읽은 개념적 무결성 용어를 참조합니다. . Brooks Jr.

책에서 Fred Brooks는 IT 팀이 어떻게 성장하고 그 증가가 생산성에 미치는 영향을 설명합니다. Fred에게 IT 팀을 확장하려고 할 때 해결해야 할 가장 큰 문제 중 하나는 팀 간의 커뮤니케이션입니다. 작업을 병렬화하려면 가능한 한 독립적 인 팀이 필요합니다. 그러나 모든 팀이 상호 연결된 플랫폼에서 작업하자마자 팀 간의 의사 소통이 필요합니다. 공통 언어를 사용하는 것이 성공의 열쇠 인 경우에 해당됩니다.

시스템, 기술 구성 요소, 인터페이스 또는 빌딩 블록이 무엇인지 논의하면서 이전 팀 동료들과 끊임없는 대화를 나눈 기억이 있습니다. 큰 IT 부서에서 일하는 경우 팀별로 이름이 다르게 지정되어 얼마나 실망 스러운지 알 것입니다. 때로는 서로 다른 이름을 사용하는 경우 최악의 경우도 있습니다.

마지막 이름의 일반적인 예는 하나의 이름으로 모놀리스 애플리케이션의 이름을 지정하는 것입니다. (모놀리스이므로) 말이 되더라도 그 모놀리스를 깨고 싶을 때 더 자세한 정보가 필요합니다. 데이터베이스, 프런트 엔드, 데이터 모델 등에 다른 이름을 도입하면 프로세스에 도움이 될 것입니다.

소규모 IT 부서에 있든 더 큰 부서에 있든 항상 시작하기에 좋은시기입니다. 명명 규칙, 서비스 / 시스템 / 솔루션 카탈로그 등을 사용합니다. 앞으로 얼마나 커질 지 알 수 없습니다.

개념적 무결성에 대해, 나만 알수록 빠를수록 좋습니다.

강제 설계 대화

제 생각에 문제에 대한 모든 솔루션은 항상 구현하기 전에 상황 분석 및 솔루션 설계. 개발 팀의 현실은 매주 해결해야 할 새로운 문제가 있다는 것입니다. Business as Usual 루틴으로 몇 달 후에 팀은 자동 조종 장치로 실행되기 시작하고 중장기 적 영향에 대해 너무 많이 생각하지 않고 문제에 대한 해결책을 찾습니다.

개발 팀에 통합 된 아키텍처 기능은 항상 도움이됩니다. 우리가 직면 한 문제에 대한 최상의 솔루션을 찾기 위해 디자인 대화를 늘리는 것입니다.

또한 디자인이 시작 단계에서해야 할 일로 간주되는 구식 개발 프로세스에 도전하고 싶습니다. 계획.기사 건축가 엘리베이터 — 위층 방문 , Gregor Hohpe 는 아키텍처 역할에 대한 나의 이해를 완벽하게 설명합니다.

“… 따라서 모든 중요한 결정을 한 사람에게 맡기는 대신 프로젝트 위험을 되돌릴 수없는 결정의 수를 최소화합니다 .”

아키텍처가 모든 개발 프로세스에 있어야합니다. . 실제로 Agile에서 작업하는 경우 모든 반복에서 결정을 내릴 것입니다.

전략 토론

IT 담당자로서 저는 회사 이사회에서 매우 구체적인 그리고 상세한 기술 토론. 중대형 기업의 현실은 이사회 구성원이 세부 사항에 대해 너무 깊이 들어갈 여유가 없다는 것입니다. 하지만 회사 이사회가 IT 상황을 이해하지 않고 전략에 대한 결정을 내려야합니까?

현재 세계에서 IT가 전략의 중심에 있지 않다고 말할 수있는 기업은 몇 개 밖에 없습니다. 그렇다면 전략을 IT로 또는 그 반대로 번역하는 책임자는 누구입니까? — 당신은 이미 답을 알고 있습니다.

TUI Destination Experiences 아키텍처 팀에서 가장 큰 공헌 중 하나는 타겟 아키텍처 모델을 그리는 것이 었습니다. TAM을 사용하면 IT 직원이 아닌 사람이 당사의 주요 솔루션 및 시스템과 이들이 회사 가치 흐름에 연결되는 방식을 이해할 수 있습니다. TAM을 배포 한 후 대부분의 전략 대화는 아키텍처가 어떻게 생겼는지, 새로운 상황에 어떻게 적응해야하는지 살펴 보는 것으로 시작되었습니다.

그러나주의해야 할 점은 타겟 아키텍처 모델이 정적 인 것이 아닙니다. “있는 그대로”및 “예비”아키텍처의 그림. 그런 종류의 운동을 시도하면 특정 프로젝트에 딱 맞는 일시적인 무언가로 끝날 것입니다. 제 생각에는 아키텍처의 주요 구성 요소를 그리고 보존하려는 항목을 선택하고 (비즈니스의 핵심이기 때문에) 변경하거나 발전해야 할 항목을 가리키는 데 집중하는 것이 좋습니다.

TAM 프레젠테이션의 첫 번째 슬라이드

Visa 설립자 인 Dee Hock의 말을 항상 기억하십시오.

간단하고 명확한 목적과 원칙은 복잡한 지능적 행동을 유발합니다. 복잡한 규칙과 규정은 단순한 어리석은 행동을 낳습니다.

무한대 이상

애자일에 대한 집착은 때때로 IT 팀을 단기 의사 결정자로 바꾸는 것입니다. . 이미 논의했듯이 우리는 오늘 내리는 결정이 미래에도 보장되는지 확인해야합니다. 때로는 장기적으로 전략에 대한 명확한 견해를 갖는 것을 의미합니다. 때로는 미래에 맞지 않는 솔루션에 갇히지 않도록 조심해야합니다. 대부분의 경우 기본 수준의 품질을 보장하고 모든 상황에 적응할 수 있음을 의미합니다.

이미 언급했듯이 아키텍처는 전략적 수준에서도 작동해야합니다. 즉, IT 플랫폼에 영향을 미칠 수있는 미래 가능성에 대한 새로운 정보가있을 것입니다. 때로는 그러한 전략적 변화가 기밀로 유지되기도합니다. 후회하는 움직임을 피하기 위해 어떤 결정에 영향을 미칠 수 있다는 것은 때때로 어려운 일입니다. 왜냐하면 무식한 사람들은 그 뒤에 숨은 진짜 이유를 결코 이해하지 못할 것이기 때문입니다.

어떤 시점에서 우리는 그 중간에있었습니다. B2C 플랫폼의 아키텍처 개선에 대한 논의. 아키텍처를 많이 개선하는 것은 정말 의미가 있습니다. 하지만 우리 중 일부는 B2C 플랫폼을 대체 할 회사를 인수하기 위해 대화 중이라는 사실을 알고있었습니다.

저를 믿으세요. 건축가가되는 것이 항상 쉽지는 않지만 항상 무엇이 무엇인지 생각해야합니다. 회사에 가장 적합합니다.

또한…

… 또한 우리는 그림 그리기를 좋아하고 사무실을 훨씬 멋지게 만들 것입니다.

아키텍처 다이어그램을 사용하여 토론하는 개발 팀

겸손한 게시물을 바랍니다. 미래에 이러한 아름다운 직업을 이해하는 데 기여하십시오.

Tui Destination Experiences의 기술 도메인 책임자 인 Migue Coll