- UID
- 120068
- 热情
- 9041
- 人气
- 10872
- 主题
- 163
- 帖子
- 4459
- 精华
- 2
- 积分
- 12334
- 分享
- 0
- 记录
- 0
- 相册
- 0
- 好友
- 3
- 日志
- 0
- 在线时间
- 6239 小时
- 注册时间
- 2010-7-12
- 阅读权限
- 30
- 最后登录
- 2022-6-28
升级 46.68% - UID
- 120068
- 热情
- 9041
- 人气
- 10872
- 主题
- 163
- 帖子
- 4459
- 精华
- 2
- 积分
- 12334
- 阅读权限
- 30
- 注册时间
- 2010-7-12
|
This is initiated from another discussion from another topic, but the original LZ ask the thread to be deleted.
So I pickup from last discussion and continue here.
I can't speak for Infrastructure Architect or Network Architect.
But here's my understanding to various other architect roles:
1. Domain Architect (may also known as Solution Architect)
This is usually a in-house role within a big enterprise, and this role will look after a particular functional area. It can be categorised in technical area, i.e. CRM, Integration, Online, Billing, Payment, BI/DW etc... But in reality you still nee have knowledge in other IT domains, it's very rare a IT solution don't cross multi-domains. Sometimes Domain refer to business area, i.e. Banking, Utility, Telco, Insurance.
The daily work involved with this kind of role is extermely diversed, engage with business stakeholder, write design document, lead solution process, lead SDLC, lead problem diagnosis / triage, business case analysis / calcucation, business impact analysis, project scoping / cost estimation, vender selection, working with vendor, and may need get your hand dirty and get involved in development / test / operation tasks too.
Above all else, this role need to work with extermely ambigious and abstract business concepts and somehow turn it into a tangible deliverable software solution.
But you often don't need to resolve real technical issue, typically you just find out what the problem is, then hand over to vendor / dev / BAU team to resolve. However sometimes identify the root cause of problem is the hardest part.
2. Technical Architect / Consulting Architect (may also known as Solution Architect too)
This is usually a customer-facing role specialising at a software product. This person is a subject matter expert with a particular product. This role is far more technically orientated compare to domain architect. You are engaged to complete a specific task. The role is technically more challanging, but the nature of work is less ambigious.
3. Generic Solution Architect
This is usually from a Software Vendor that dont own any software product themselve. i.e. Datacom, Intergen, Provoke, Optimation etc... This is like half way between above 2 categories. You need deal with ambigious business ideas but you also need to work on hard-core technical problems. Good thing is you may get to learn new product and new technology on every new engagement. Bad thing is you don't normally get to choose what project you work on.
4. Enterprise Architect
This is like Domain Architect but one level up. There is actually a lot overlapping areas between EA and Domain Architect / Soluation Architect. But EA will spend more time on defining roadmap, deciding which project is to be delivered with which platform, decide which application to decommision etc... And EA will spend less time on actually deliver the project. There is a joke I heard that say EA normally don't even care if a proposed solution actually work or not, it's not their problem. There is certain degree of truth to that joke.
|
|