虽然业界有关什么是“软件架构”有着明确的定义及共识，但是确实没有软件架构师的定义。简单地讲，架构师是一个技术控制的角色。技术控制是从客户或市场开始，一直到交付或服务的整个链条。如果大家对一个应用研发机构或产品研制机构的主要活动熟悉的话，就知道该链条上存在很多需要架构师负责的控制点。以西门子为例，西门子的战略市场部门就会和业务部门的很多架构师进行协作。这主要是由于战略市场部门的职能之一就是对未来十到十五年的技术和创新进行预判。这样的技术预判，如果没有架构师作为技术控制，单凭MBA出身的市场人员，大家能相信这样的技术预判吗？所以架构师需要具备一定程度的技术及创新预判能力。
从一个架构师的日常工作来看，他面对的基本上有七大问题：商业问题、系统问题、子系统问题、构件问题、技术问题、流程问题、项目管理问题。其中，前五项是一个架构师主要负责解决的。这里我尝试提几个问题，让大家检验一下自己是否具备解决这些问题的能力。
如果进行企业应用开发，你知道经典的商业运营手段一般有哪些吗？例如：公司中一般有哪些典型的职能机构？最经典的公司财务部运作是什么样的？最经典的公司纯研究机构的运作是什么样的？或者，最经典的公司纯销售机构是怎样运作的？
如果你负责一个实时系统的架构，经典的架构构建步骤有几步？一个医学CT机系统应该用什么架构风格来构建？军用舰艇上的3C系统又应该使用什么架构风格？除了我们都熟悉的MVC风格的架构，你还知道哪些架构风格？再具体一些，对于系统的并发问题，你知道业界流行的经典解决手段包括哪些?
如果你负责子系统及构件设计，经典的设计步骤有几步？分别又有哪些活动？除了你熟悉的Gang of Four的23个设计模式，你还知道什么设计实践？再具体一些，设计中有关同步、事件、资源管理等，你知道哪些前人的最佳实践呢？
实践工作中，我们遇到的现实是：盲目追随业界通用框架，即对框架或中间件的严重依赖。这些框架或中间件背后实际隐藏了很多技术、设计、应用场景，也就是说为设计开发人员隐藏了很多系统设计开发的复杂性。如果架构师把各项系统级架构质量的要求，想当然统统扔给这些框架或中间件去处理，将会带来灾难性的后果。业界有这样一句话：“框架或中间件是用来帮助你的，而不是代替你去思考和工作的。”所以我们必须根据现实的系统要求，自己动脑筋去构建适合现状的软件架构！
简而言之，架构师需要具备的能力=熟知最佳实践+动脑灵活使用+技术及创新预判。