一个中小型的企业也许根本没有或者只有1-2个人担任IT架构师的职位，企业规模逐步扩大
，才到成立专门的架构部门或者专门的架构组。
如何才能让架构部门更好的工作，有以下几个方面可以考虑，也就是架构的架构。
1、划定自己工作职责的圈圈
确定有哪些架构是需要管理的，基础架构、应用架构、数据架构、网络架构、运营架构、 安全架构等等，划分应按照单一维度进行，保证不会重复。按城市的规划打个比方，一个城市哪里应该是公路，哪里是住宅，哪里是商业，哪里是医院、商场，这是一种规划，而再细节一点，到建设一个街区、建设一幢大楼，
在此基础上，部门的岗位规划基本确立，也就是目前不管有多少人，也许很少，但是完成的实际是多个岗位应完成的职责，在未来有需要或者规模进一步扩大的情况下，岗位还要独立出来。
然后是确立各个岗位或者所有岗位应完成的工作内容，通用的比如，制定架构规范、修订设计文档模板、根据项目要求设计合适的架构，进行工作量估算，参与评审详细设计方案等等。
2、建立与其他部门或岗位的联系，与相关部门连线在划定了自身的工作范围之后，架构本身的工作一定不是独立的，需要落地实施就需要与
需求部门、研发部门、测试部门、运维部门建立各种联系。
与需求部门，需求从战略或业务发展的角度提出系统或项目建设的需求，架构人员则考量其实施的主要方向、落地的规划、是否现有符合现有架构等。
与研发部门，这个非常关键，与落地实施的程度密切相关，需要加强与具体设计的技术人员的宣讲，让架构规范的内容有更加通俗易实施的纲要和指导意见。就好比建筑工人看不懂蓝图，架构师负责蓝图设计，具体的设计师负责将蓝图中的某一部分细化，比如管道、电路的设计更加具体、更加易懂。让每一个开发人员去详细学习架构规范并不现实，有时具体设计人员的直接指导更加管用。
与测试部门，包括性能测试、非功能测试、安全测试，需要达到哪些架构规划中的效果和指标，要跟他们保持一致
与运维部门，部署架构、网络架构等需要提前规划，以免项目实施已经完成再因为部署问题调整实施方案。
3、制定完善和优化的制度流程，画出箭头方向，PDCA(PLAN-DO-CHECK-ACTION)
要不断完善架构的规范，规范的制定一定要尽可能收集更广泛的意见，并加强宣传讲解。
反之，即使规范写的再完美，没有实施的条件，也就是一纸空文。
有些时候需要架构来指导别人，箭头指向外部；
有些时候实施人员需要决策时，需要架构人员的帮助，箭头则指向架构组内部。
一个好的制度和规范，一定是根据实施情况不断修改和优化的，在制度和规范发布后，首先让大家广泛可得，有机会就解释、说明、指导，在此过程中，收集实施人员的意见和建议，回过头再完善制度和规范，做到PDCA的循环。
4、制定部门发展路线
架构的组织者应当对当前和未来的形式有清晰的把握，企业当前的架构处于什么状态，在什么样的时间要做哪些事情，达到一个新的什么样的状态。
5、如何与时俱进，应对新技术的冲击
新技术层出不穷，区块链、大数据、微服务、云计算、分布式等等这些技术会对企业的架构产生较大的影响。在架构组内部要有一个浓厚的学习和分享的氛围，要像草原上天亮时的斑马，如果不抓紧奔跑，危险将随后而来。