企业架构师计划

从开始到接受

1. 首先寻求了解。
2. 1. 不要为了EA而做EA。 真正寻求了解客户的需求。 他们是否需要和EA计划一起解决对业务至关重要的问题。
   2. 这可能不仅仅是举行会议和研讨会。 以经验丰富的专业人士的经验来了解企业，业务策略，实际的利益相关者，业务的难点，主要的利益相关者等。对需要解决的问题形成清晰的想法。 长期（不超过3年）和短期（不少于6个月）。
   3. 尽可能简单地放下“问题陈述”，而不是简单。 让关键的利益相关者写下来和/或成为明确表达和分发的过程的一部分。 这将使您更容易让他们认可问题–如果他们选择有一个解决问题的方法，则可以向EA程序提供支持。
   4. 通过明确指出要交付的内容和不交付的内容来限制“问题陈述”的范围。
3. 一旦您确定了“问题”， 请放一点点盐，因为“问题”声明永远不会被真正确定，任何EA都会天真地不定期从关键点重新确认问题声明利益相关者 –从倒退开始
4. 1. 您需要什么信息来解决问题？ 您什么时候需要它？ 谁来提供？ 谁控制信息？ 信息提供者和控制者是否购买了EA计划的成功？ EA计划是否不利于这些关键推动因素中的任何既得利益？
   2. 所有这些信息如何相互链接。 哪个信息输入到哪个决定，哪个决定又导致哪个信息。 导致特定问题答案的输入的相互关系是一个框架 。
   3. 选择框架不同的通用框架是Zachman ， TOGAF等。通用框架（如果您选择一个框架）只是起点。
5. 不要屈从于必须从解决方案开始的压力。 如果您从一个框架开始并让它不断发展，就会在适当的时候出现一种解决方案，该解决方案是特定于企业的，并且是每个企业所独有的。
6. 1. 预计EA解决方案将适合企业，并且不足以使它们适合项目。
   2. 最好有一个适合企业的解决方案，而不是像手套一样适合所有项目。
   3. 诀窍是提出一个适用于企业的框架，该框架具有扩展点，各个项目可以在需要时将其放入特定的扩展中。
7. 提取数据以馈入框架- 希望它能带来答案。
8. 1. 如果您到目前为止一直在研究技术，那么这可能是您将要面对的最困难的智力障碍/挑战。 也许这是您职业中的第一次–工作的成功并不取决于您能否找到合适的技术/ API /工具/软件。 没有正确的答案。 至少没有办法立即证明您得到的答案是正确的。
   2. 一旦定义了“问题”并确定了范围，并在“框架”上封闭了，那就是为框架获取正确，充分和相关的信息。 解决方案可能来自管理人员，生产线，领域等。
   3. 所以，计划一下。 列出所需的信息（信息，统计数据，报告...），所需的位置（利益相关者，生产线，首席执行官等），要收集的信息（面试，研讨会，在线调查...）。 确定收集此资源所需的资源–人员，工具，归档等。确定依赖关系，关键里程碑。 制定计划。
   4. 走。 执行计划。
9. 在理想情况下，EA的输出可能是100％正确的。 在现实世界中-随着不断变化的业务场景，瞬态业务优先级，围绕数据正确性的内在问题-预期会出现错误，并教育关键利益相关者也预期会出现错误。
10. 1. 来自软件技术背景的人们将面临的另一种精神障碍/挑战。 那些习惯于看到自己的解决方案可以编译，执行，看到解决方案可以解决问题并且能够证明问题已经解决的人–会发现自己正在为自己的目标而努力，即“大致正确”且没有​​证明的解决方案。
    2. 实际上，对于EA（EA）努力寻求可证明的解决方案，这是确定的失败方法，对于除最小规模的企业以外的所有企业都是如此。 该输出旨在设定广泛的方向。 除非有一些实现能够真正实现这一广泛方向的实现，否则它永远是不正确的。
11. 知道在哪里停下来
12. 1. 您作为EA所做的任何事情都必须是可重用的。
    2. 如果您不是作为整个组织，则无论您以EA形式交付的任何内容都必须（至少）适用于多个项目。
    3. 每当您分配/选择了不可重用/不适用于多个项目的内容时，请停止。 不要这样 将其移交给项目团队。 让他们也玩得开心。
13. 知道要避免什么
14. 1. 避免做出决定。 我不是要笑。 我是认真的 EA实施“解决”的事务包括业务，项目，财务等事务。有些人的工作正在执行解决方案，例如CEO，项目经理，CFO等。您的角色是咨询。 您为人们提供有关“企业问题”的建议，其中包括多项建议，一项建议和原始数据（如果他们选择研究的话）。 但这是您应该划清界限的地方。
    2. 不要陷入技术大战-Java与.Net –敏捷与瀑布–根本不适合您。 建立一个框架。 与主要利益相关者就框架达成协议。 获取数据-将其推送到框架中-提出建议并将其移交给其他人。
    3. 仅为了证明上述观点，让我们想象一个场景：您可能已经提出了一个支持.Net的建议（在Java与.Net决策过程中），并将其交给了Delivery Manager –他最终可能选择Java是因为某些基于Java的软件公司可能已经破产，因此资源突然变得很容易获得。 这不是基于技术的决策。 市场上没有人预见到这件事。 让Dellivery经理来完成最适合其可交付成果的决策，而Dellivery经理的职责是及时并在预算范围内交付软件产品。 让他向首席执行官证明，从长远来看，这对企业最有利。 不要被妨碍阻碍业务成功，因为它违反了一些EA的发现。
15. 知道何时以及如何说“不”
16. 1. 根据定义，任何范围如果未经检查，都有爆炸的趋势。 但是，尽管开发人员的工作范围只能增加这么多，但EA程序的范围可能占很大的比例，除非非常积极和例行地控制。
    2. 分配给EA的大部分活动将是多年努力，甚至更多。 但是，一旦业务出现糟糕的季度，企业为某个计划提供资金的需求就可能开始紧张。 采取迭代方法（半年周期）以实现对任何任务的连续可测量速度至关重要。
    3. “当前迭代的范围超出范围”，“当前迭代未被批准”，“将其添加到将来的迭代的讨论列表中”是拒绝的方式，这不应该在企业界引起太多麻烦。 像练习小猫中的任何其他工具一样，练习这些短语。
17. 从“象牙塔”下车，结交朋友。
18. 1. 鉴于EA活动的输出往往对组织具有限制性和规定性，因此EA可能会被视为在“象牙塔”中工作。 这在两个帐户上是错误的。 首先，这意味着宣传EA活动和出售产品更加困难。 其次，这意味着EA没有获得足够的特定于组织的信息，因此，针对特定组织定制输出的可能性较小。
    2. 下到工作区，欢迎/邀请/允许/奖励参加EA活动的聪明人。 这将使您的工作更加轻松，并为您赢得更多的朋友-这都是EA计划成功的关键。

工作正在进行中 …

参考： Technology Enterprise博客上的JCG合作伙伴 Partho的组织架构师 。

翻译自: https://www.javacodegeeks.com/2012/08/enterprise-architect-program-for.html