英文ppt结尾欢迎您的意见_不受欢迎的意见，您需要大型的前期设计

英文ppt结尾欢迎您的意见

您需要大型的前期设计(You need a big upfront design)

You’ve probably heard that creating extensive designs of your system upfront is a waste of time and effort. This idea is borne from the theory that in a world of agile iteration, you can develop your designs as you go and evolve an emergent architecture based on real-world feedback. I’m here to tell you: this thinking is naive and will do considerable harm to your delivery of enterprise systems.

您可能已经听说过，在系统上预先创建广泛的设计是浪费时间和精力。 这个想法是基于这样的理论，即在敏捷迭代的世界中，您可以在进行过程中进行设计，并根据实际反馈来发展新兴的体系结构。 我在这里告诉您：这种想法很幼稚，会对您交付企业系统造成很大的损害。

大众意见： (The Popular Opinion:)

There are plenty of articles that declare a big upfront design an ineffective and antiquated practise only done by the relics of the waterfall era. Much of this rhetoric is recited by organisations trying to embrace an agile approach to delivery. It generally boils down to the following reasons:

这里有大量的文章是申报一个大的预先设计一个无效的和过时的做法只能由瀑布时代的遗物完成。 试图采用敏捷交付方法的组织都引用了许多这种言论。 通常可以归结为以下原因：

• Requirements can’t be fully understood upfront.
  需求不能完全被预先理解。
• By the time you’ve completed the design, it will be out of date.
  在完成设计时，它已经过时了。
• You can’t know enough upfront to design everything.
  您可能没有足够的前期知识来设计一切。
• Without doing, there is no learning.
  没有做，就没有学习。
• The scope of your design can grow out of control and be hard to finish.
  您的设计范围可能会失控，难以完成。
• Technology engineering is not like civil engineering.
  技术工程不像土木工程。

And on the face of it, these don’t sound too unreasonable, do they?

从表面上看，这些听起来不是很不合理，是吗？

The original pioneers of this idea tend to mean that the design is fully detailed before any build work starts and then set in stone until final delivery. However, this ideology is more often used as a justification to avoid any meaningful upfront design and leave it to be done ‘just-in-time’ while building the solution. This is the interpretation we’ll be addressing here since it is the most common and problematic.

这个想法的最初开拓者倾向于在开始任何建造工作之前对设计进行充分的详细说明，然后将其固定下来直至最终交付。 但是，这种意识形态通常被用作避免任何有意义的前期设计并在构建解决方案时“及时”完成的理由。 这是我们将在这里处理的解释，因为它是最常见和最有问题的。

Even so, it isn’t difficult to understand why this is a common way of thinking. There is something very gratifying about getting on and building things, which fits nicely with delivery managers wanting to show clear and rapid tangible progress to the business. So it is hard to resist this confluence of desires and ideology. However, this can easily lead the inexperienced down a very tricky path.

即使这样，也不难理解为什么这是一种常见的思维方式。 进行和构建事物非常令人满足，这与希望显示清晰，快速的实际业务进展的交付经理非常吻合。 因此，很难抗拒欲望和意识形态的融合。 但是，这很容易导致缺乏经验的人走上一条非常棘手的道路。

There are, however, good reasons why this thinking has come about that we should not dismiss. Some organisations, and certainly far too many historically, have failed to deliver projects successfully because the design was both overly time consuming and ultimately not fit for purpose. Architects can become detached from the reality of the business (strategic goals, financial constraints, economic factors, user needs, etc.) as well as from the practicalities of the delivery process.

有，但是，为什么这种思想已经发生了，我们不应该解雇理由。 一些组织，当然还有太多的历史组织，都未能成功交付项目，因为设计既费时又最终不符合目的。 架构师可能会脱离业务的实际情况(战略目标，财务约束，经济因素，用户需求等)以及交付过程的实用性。

All in all, it is easy to sympathise: The organisation is not delivering because the design process blocks them. So it is not unreasonable to challenge upfront designs and to suggest evolving the design incrementally and collaboratively.

总而言之，很容易产生同情：组织无法交付，因为设计过程阻止了他们。 因此，挑战前期设计并建议以渐进和协作的方式发展设计并非不合理。

为什么这是错的 (Why this is wrong)

Unfortunately, this ‘anti-upfront-design’ approach can be a dangerous one; mainly because the interpretation of this ‘sound-bite strategy’ leads organisations to avoid upfront design & architecture altogether (or at least minimise it to a level of uselessness). Teams tend to avoid things they’re either not so good at or connected with, so they can focus on what they do best (a developer-focused team will naturally want to write code and build things).

不幸的是，这种“反前期设计”方法可能是一种危险的方法。 主要是因为对这种“咬咬策略”的解释导致组织完全避免了前期的设计和体系结构(或至少将其最小化到无用的程度)。 团队倾向于避免自己不太擅长或与他人无关的事情，因此他们可以专注于自己最擅长的事情(以开发人员为中心的团队自然会希望编写代码并构建事物)。

Many organisations, therefore, have minimised the architect’s role and empowered developers to “just go deliver things”. Initial results are usually exciting — something tangible is ready sooner, and the business stakeholder feels more engaged and empowered too. All in all, everyone feels like this is a productive and effective approach…

因此，许多组织都将架构师的作用降到了最低，并授权开发人员“立即交付”。 最初的结果通常是令人兴奋的-有形的东西会更快地准备好，并且业务利益相关者也会感到参与和授权更多。 总而言之，每个人都觉得这是一种高效有效的方法……

Until we realise that our plans aren’t working out in the long term, the delivery has slowed down, maybe even stopped. We find it hard to meet the project requirements. Making changes is difficult. And it is hard to reason about the system or communicate how it works to key stakeholders (e.g. security) because the design documentation is missing or inadequate, and the team only have the ghosted outlines of past whiteboard sessions around the office, along with the lingering scent of hopes and prayers and a recycling bin full of good intentions.

直到我们意识到我们的计划无法长期执行，交付速度才开始放缓，甚至停止。 我们发现很难满足项目要求。 进行更改很困难。 而且，由于缺少设计文档或设计文档不足，很难对系统进行推理或将其工作方式传达给关键的利益相关者(例如安全性)，并且团队只有过去在办公室周围白板会议的鬼影轮廓以及挥之不去的充满希望和祈祷的香气，以及充满良好意愿的回收箱。

Worse still: the solution, when implemented by multiple teams collaborating without this upfront cross-cutting design, starts to resemble a slightly demented and sickly chimaera crossbreed of competing ideas and styles, with inconsistencies and incompatibilities that would put the Winchester Mystery House to shame.

更糟糕的是：该解决方案由多个团队在没有这种前期交叉设计的情况下进行协作而实施时，开始类似于竞争激烈的想法和风格的，有点痴呆和病态的希马拉杂种，不一致和不兼容会使Winchester Mystery House感到羞耻。

The Winchester Mystery House is a sprawling, architectural oddity, with a lot of complexity and inconsistencies: Doors open to the outside from the first and second floors with 20–30ft drops, stairs that lead up to blank walls, buckets full of keys, rooms that are totally walled in (and only recently discovered), and much more — all as if it had been built without any real forethought or design.

温彻斯特神秘屋(Winchester Mystery House)是一个庞大的建筑奇特建筑，具有许多复杂性和不一致之处：门从一楼和二楼向外开放，跌落20至30英尺，楼梯通向空墙，装满钥匙的桶，房间完全被围起来(并且只有在最近才发现)，还有更多–好像它是在没有任何真正的前瞻性或设计的情况下建造的。

Creating the design as you go means:

创建设计，当您去手段：

1. You will not have enough understanding of the design to be able to plan the delivery sequence of complex, shared, or high dependency capabilities, which will attack your critical path at every opportunity.

   您将对设计没有足够的了解，无法计划复杂，共享或高依赖性功能的交付顺序，这将在每一个机会中攻击您的关键路径。

2. You will not see significant pitfalls of a chosen approach (technical or otherwise) that only become apparent when you work through the way the entire design interacts with itself and others.

   您不会看到选择的方法(无论是技术方法还是其他方法)的重大陷阱，只有当您按照整个设计与自己和其他人交互的方式进行工作时，这些陷阱才会变得明显。

3. You will not find opportunities to simplify the build work — e.g. identifying repeating patterns very early will enable a re-usable component or capability to be created. Doing this as you go will mean continual refactoring whilst on the critical path for delivery and without a coherent/broad view of requirements — which will lead to a lot of disruptive breaking changes.

   您不会找到简化构建工作的机会-例如，尽早识别重复模式将使可重复使用的组件或功能得以创建。 随心所欲地执行此操作将意味着在交付的关键路径上进行连续重构，并且没有一致/广泛的需求视图，这将导致很多破坏性的重大更改。

4. You will not be able to partition the system into cohesive yet minimally coupled deliverables so that teams can work together with minimal dependencies (which create delivery complexity).

   您将无法将系统划分为内聚但耦合最小的交付物，因此团队可以以最小的依赖关系进行协作(这会增加交付复杂性)。

5. You will not be able to bring the team together under a shared understanding of the system and where/how they fit into realising it.

   您将无法将团队聚集在一起，对系统以及他们在什么地方/如何实现该系统有共同的了解。

6. You will not be able to plan your delivery with any kind of meaningful results: dates, finances, risk management are even more unreliable without adequately understanding what it is you will be building.

   您将无法以任何有意义的结果来计划交付：日期，财务，风险管理甚至在不充分了解要构建的内容的情况下更加不可靠。

7. You will build the first design that solves the first challenge you experience. Rarely is your first attempt at anything the correct answer. Designs that have had several (constructive) review cycles are much more durable than those that haven’t. (Even better if they are practically tested/validated)

   您将构建第一个解决您遇到的第一个挑战的设计。 您很少会尝试任何正确答案。 具有多个(建设性)审查周期的设计比没有审查的设计具有更强的耐用性。 (如果经过实际测试/验证，那就更好了)

Note: When we talk about ‘design’ here, we are not talking about adding a new widget to a web page, adding a new FAQ section, or changing your colour scheme; we are talking about full solution or system design.

注意：在这里谈论“设计”时，我们并不是在向网页添加新的小部件，也不是在添加新的“常见问题”部分，或者更改您的配色方案。 我们正在谈论完整的解决方案或系统设计。

Unfortunately, there can be a tendency to treat systems as just a set of independent features. Whilst this is part of the equation, it is not all of it — we tend to ignore the most effective way to make building those features easier and cost-effective: good solid architecture. It is this total system design view that we fail to deliver when it is needed: upfront.

不幸的是，可能存在将系统视为一组独立功能的趋势。 尽管这是等式的一部分，但并不是全部—我们倾向于忽略使这些功能更容易且更具成本效益的最有效方法：良好的实体架构。 我们无法在需要时提供这种总体系统设计视图： upfront 。

For my book Mastering Digital: How Technology Leaders, Architects & Engineers build Digital Enterprises of the Future, I interviewed CTOs, CIOs, Chief Architects, and other senior technology leaders to understand what challenges they experienced in leading change in technology organisations. A common theme was the lack of a coherent big picture view of systems architecture (whether at the enterprise or solution level), and the problems that this created throughout the entire delivery process and beyond.

在我的《掌握数字：技术领导者，架构师和工程师如何构建未来的数字企业》一书中，我采访了CTO，CIO，首席架构师以及其他高级技术领导者，以了解他们在领导技术组织变革中遇到了哪些挑战。 一个共同的主题是缺乏对系统体系结构(无论是在企业还是解决方案级别)的连贯全局视图，以及在整个交付过程及以后的过程中造成的问题。

And again, in the Mastering Digital: State of Software Engineering Report, over 50 Architects and Engineers from around the world working in different types of organisations provided feedback on the issues they experienced day-to-day, and they found that the lack of coherent design and delivery-guiding architecture, as well as the bias toward features over foundations, has led to a lot of compromises and therefore technical debt.

同样，在“掌握数字：软件工程状况报告”中，来自世界各地的50多位架构师和工程师在不同类型的组织中工作，就他们每天遇到的问题提供了反馈，他们发现缺乏连贯性设计和交付指导体系结构以及对基础功能的偏见导致了许多妥协，因此产生了技术债务。

I don’t believe there are any silver bullets for getting things right, but there are many poisoned chalices that will ruin even the best intentioned teams. Too many take the easier route of avoiding any real design at all and just write code, and many others get bogged down trying to wrangle the designs amidst the red fog of delivery.

我不认为有什么灵丹妙药可以解决问题，但是有许多毒液圣杯会毁掉即使是善意的团队。 太多的人采取了根本避免任何实际设计的简单方法，只编写代码，而其他许多人则陷入困境，试图在交付的迷雾中纠缠设计。

For example, this ugly reality results in a project that should take 6–9 months and less than £2m, taking over three years and more than £20m, still with no coherent design or production-ready system. True story. Seriously. Though not unique: My consulting company provided a strategy review to an organisation for an in-flight multi-year programme to determine if they were a) on target to deliver their defined technical strategy and b) were going to deliver on time successfully. The answer to both of these, sadly, was ‘no’. There were, of course, multiple contributing factors, a lot of them to do with people, culture, and overall experience of the team. However, the lack of a robust architecture and upfront design made it almost impossible to meet their two primary goals (1: reduce operational systems costs and 2: create a technology platform for delivering re-usable service-based systems) — putting the delivery of a regulatory compliance system required by millions of people in jeopardy.

例如，这个丑陋的现实导致一个项目需要6–9个月，不到200万英镑，耗时三年，超过2000万英镑，但仍没有一致的设计或生产就绪系统。 真实的故事。 说真的尽管不是唯一的：我的咨询公司为组织进行了一项针对飞行中的多年计划的战略审查，以确定他们是否a)达到了确定的技术战略目标，以及b)能否按时成功交付。 不幸的是，这两个答案都是“不”。 当然，有多个因素，其中许多因素与团队的人员，文化和整体经验有关。 但是，由于缺少健壮的体系结构和前期设计，几乎无法实现其两个主要目标(1：降低操作系统成本，以及2：创建用于交付可重用的基于服务的系统的技术平台)—数百万人面临危险的监管合规系统。

So, if doing everything upfront is problematic, and doing everything as you go is problematic — what do you do?

因此，如果预先做所有事情都是有问题的，而随便做所有事情都是有问题的，那么您会怎么做？

不受欢迎的意见： (The Unpopular Opinion:)

There’s no escaping the need to create a proper design if you want to create any kind of reasonably complex system that will have longevity. This design cannot be an afterthought, and it needs a lot of work upfront — it is far cheaper to redesign on paper than it is to write code (despite rhetoric to the contrary). A painful reality of systems development is that it is not just about writing a bit of code for that one feature. As an industry, we still lack the necessary maturity and discipline — we are a bit like a 5yr old football team chasing the ball around the field.

如果您要创建任何类型的相当长寿的，相当复杂的系统，就没有必要去创建一个适当的设计。 这种设计不可能是事后的想法，它需要大量的前期工作—在纸上重新设计比编写代码便宜得多(尽管有相反的说法)。 系统开发的一个痛苦现实是，不仅仅是为该功能编写一些代码。 作为一个行业，我们仍然缺乏必要的成熟度和纪律性-我们有点像5岁的橄榄球队在球场上追球。

So the unpopular opinion I put forward to you is this: invest in an upfront design before you commit to building your solution. But, it is easy to abuse sound-bite strategies, so let me explain this a little better in the following sections, highlighting these key points:

因此，我向您提出的不受欢迎的意见是：在致力于构建解决方案之前，先投资进行前期设计。 但是，很容易滥用咬人策略，因此，让我在以下各节中更好地说明这一点，重点介绍以下要点：

• You need to invest in effective foundational and flexible design upfront.
  您需要预先投资有效的基础和灵活的设计。
• You need correctly qualified and experienced people to do it.
  您需要具备适当资格和经验的人员来执行此操作。
• You need to adequately fund it and ensure it has the time & resources it needs.
  您需要足够的资金，并确保它具有所需的时间和资源。
• You need to make this design the centre of your delivery work.
  您需要使此设计成为交付工作的中心。
• You need to improve the design based on real-world feedback iteratively.
  您需要基于实际反馈反复改进设计。

Our role as architects of enterprise systems is to take control of the complexity and adapt the world to serve our needs better while preserving the integrity of the ecosystem. This requires a lot of understanding and thinking. It requires us to test and validate hypotheses and experiment without excessive cost, but also to integrate the many aspects of the complexity into a coherent whole. This is not simple, and designing things on the fly as you go is disastrously expensive in the long term — it just (unfortunately) looks productive in the short term.

我们作为企业系统架构师的角色是控制复杂性并适应世界，以便更好地满足我们的需求，同时保持生态系统的完整性。 这需要大量的理解和思考。 它要求我们在不花费过多成本的情况下测试和验证假设以及进行实验，而且还需要将复杂性的许多方面整合为一个连贯的整体。 这不是简单的事情，而且从长远来看，随手进行实时设计会造成灾难性的昂贵成本–不幸的是，从短期来看，它看起来很有生产力。

Any fool can build software — but it takes a special kind of fool to accept an industry’s long term failures and technical debt as a successful business model.

任何傻瓜都可以构建软件，但是要接受一个行业的长期失败和技术债务作为成功的商业模型，就需要一种特殊的傻瓜。

Let’s look at it this way: It is a bit like planning a trip to the other side of the continent, and simply walking outside your door and hoping for the best. At first, you are making positive progress — you are going somewhere. But you don’t know the journey or paths you could (or should) take — perhaps one is more direct, maybe one is less direct but faster. Perhaps it will rain or snow on some days, and you need to have found shelter by then (will there be any at that point?). Maybe you could have spent time upfront building a vehicle or just buying one, getting you there faster despite taking time to get started. Without forethought and planning, you will miss all of these things. However, do expect every design and plan to change when it hits the ground running — you will have to adapt to circumstances as they unfold. The better the design, the better it will cope with these changes. The absence of design does not help you here, but neither does a bad design. This is why you can’t use inexperienced people to formulate it. It requires the insight of experience, as well as several hard-earned skills and proven mental models.

让我们这样看：这有点像计划去非洲大陆的另一边，只是走到门外并希望获得最好的旅行。 首先，您正在取得积极的进展-您要去某个地方。 但是您不知道您可以(或应该)走的旅程或道路-也许一个更直接，一个也许不那么直接但更快。 也许在某些时候会下雨或下雪，并且那时您需要找到避难所(届时会有人吗？)。 也许您可能已经花了一些时间在前期制造汽车上，或者只是花了钱买了一辆汽车，尽管花了一些时间上手，却可以更快地到达那里。 没有深思熟虑和计划，您将错过所有这些事情。 但是，一定要期望每一个设计和计划在实际运行时都会发生变化-您将不得不适应不断发展的环境。 设计越好，就越能应付这些变化。 没有设计对您无济于事，但不好的设计也无济于事。 这就是为什么您不能使用没有经验的人来制定它的原因。 它需要经验的洞察力，以及一些来之不易的技能和成熟的思维模式。

为什么这会改善您的企业系统 (Why this improves your enterprise systems)

When you have a good, well-thought-out, and flexible design prepared upfront, you will begin to experience the following improvements:

预先准备好良好的，经过深思熟虑的灵活设计之后，您将开始经历以下改进：

• Your plans will be easier to create, simpler to adapt, and more accurate.
  您的计划将更易于创建，更容易适应和更准确。
• Your systems will require fewer breaking changes.
  您的系统将需要更少的重大更改。
• Adding new features will be simpler and faster.
  添加新功能将更加简单快捷。
• Changing the architecture over time will be easier and more predictable.
  随着时间的推移更改体系结构将更容易且更可预测。
• There will be a shared vision and understanding.
  会有共同的愿景和理解。

付诸实践 (Putting this into practice)

It takes hard work to deliver enterprise systems effectively. Creating that big design up-front is only one part of this and is not as ‘singular’ a task as it might first seem. Below are recommendations on how to make a design really work.

有效交付企业系统需要艰苦的工作。 预先创建大型设计只是其中的一部分，而不是看起来像初看起来那样“单一”的任务。 以下是有关如何使设计真正起作用的建议。

• Create an Upfront Big Picture Architecture: This is your foundation for almost every other part of your delivery. It should be cohesive and comprehensive, including interactions with other systems and stakeholders. It should identify lower-level components and aspects for further design work, with enough detail to be able to define the deliverables for an implementation/delivery plan, requirements for technology, possibly a business case. Solution context is essential. It is about coherence, not completeness.

  创建一个前期的大图片架构：这是交付几乎所有其他部分的基础。 它应具有凝聚力和全面性，包括与其他系统和利益相关者的互动。 它应该确定较低级的组件和方面，以进行进一步的设计工作，并具有足够的详细信息，以便能够定义实施/交付计划的可交付成果，技术要求，甚至可能是业务案例。 解决方案上下文至关重要。 这是一致性，而不是完整性。

• Create an Upfront Design Plan: Create a plan upfront of how you will develop the design, and at what stage of the process. This should include a design artefact map and a phased view of its maturation — either by adding lower-level design details (e.g. physical component designs) or improving a draft / speculative design with feedback from doing something real (e.g. PoCs).

  创建前期设计计划：在您将如何开发设计以及在流程的哪个阶段创建一个前期计划。 这应该包括设计伪影图和其成熟度的分阶段视图-通过添加较低级别的设计细节(例如，物理组件设计)或通过做事的反馈(例如PoC)来改进草稿/投机设计。

• Create Candidate Component Designs & Identify PoCs: It is crucial to start to flesh out how your big picture design will work in practice. Like how a specific component handles the processing you expect it to do and how it technically interacts with other elements. You need to investigate things that are not obvious or well understood. You don’t need to detail everything at this stage — you’ll come back later and refine. Do just enough. Where you are not sure about something, define a PoC (Proof of Concept) to test the idea.

  创建候选组件设计并确定PoC：开始充实大图片设计在实践中的工作至关重要。 就像特定组件如何处理您希望其执行的处理，以及该组件与其他元素的技术交互方式一样。 您需要调查不明显或不了解的事物。 您无需在此阶段详细说明所有内容-稍后再进行细化。 做刚好。 如果您不确定某件事，请定义一个PoC(概念验证)以测试该想法。

• Coherence vs Completeness: Detail and refine designs incrementally over time — your big picture architecture should describe enough of its characteristics to explain how it is structured and how things will interact with each other consistently — creating coherence in the solution. Then you can plan a series of lower-level designs that can iteratively build upon this macro perspective: first, get a rough design done to validate the solution context expectations, and then detail to the implementation level just in time for development.

  一致性与完整性：随着时间的推移逐步细化和细化设计-您的总体架构应描述其足够的特征，以解释其结构以及事物之间如何始终如一地交互-在解决方案中创建一致性。 然后，您可以计划一系列可迭代地基于此宏观观点进行构建的较低级别的设计：首先，进行粗略的设计以验证解决方案上下文的期望，然后及时将其详细描述到实现级别以进行开发。

• Design for Change: You must consider as much of the solution context (inside and outside) as is possible to understand constraints, drivers, and both short term and long term goals for your design (even things out of scope right now). You can use this understanding to create a design that meets the bigger picture needs, whilst still being practical (and incrementally deliverable) enough for the initial scope of work. Change will always happen, but your design can survive and adapt better if you plan for it. Be mindful of dependencies, interfaces, and separation of concerns here.

  变革设计：您必须尽可能多地考虑解决方案上下文(内部和外部)，以了解设计的约束条件，驱动因素以及短期和长期目标(即使目前不包括在内)。 您可以利用这种理解来创建既可以满足更大图片需求的设计，又可以满足初始工作范围的实际需求(并且可以逐步交付)。 变革将永远发生，但您的设计可以存续并更好地适应。 请注意此处的依赖性，接口和关注点分离。

• Avoid Early Technology/Tool Coupling: The design should avoid too many tight couplings with technology/tools until you need to understand the technology’s constraints to make the implementation physical; otherwise, it will become brittle and difficult to change. You should consider the capabilities and constraints of applicable technologies/tools to help avoid surprises, but not as the bulk of the design. Use a solution/enterprise architect, not a technology specialist at this stage. Don’t select your tools before you design the big picture architecture.

  避免早期的技术/工具耦合：设计应避免与技术/工具的过多耦合，直到您需要了解技术的约束条件以使实现物理化为止。 否则，它将变得脆弱且难以更改。 您应该考虑适用技术/工具的功能和约束，以帮助避免意外，但绝不像设计中那样。 在此阶段，请使用解决方案/企业架构师，而不是技术专家。 在设计全局架构之前，请不要选择工具。

• Have a Plan and Plan for Change: Delivery plans will never be entirely accurate. That’s OK. The initial goal is to roughly shape resource requirements (team, budget, schedule, suppliers, etc.). Generally, it should describe your route, timetable, and status so that you can see if you are on course and align with other teams dependent on your plan. This kind of plan is not about daily tasks at this stage — that’s for lower-level planning, e.g. sprint planning. Continually improve it based on increasing knowledge of the work and performance. The plan should not be static. Always build iteration, feedback, and improvement time into the plan. This can work with a SCRUM agile approach or a simpler Kanban workflow, so there is no need to forego the value of these methodologies whilst still having a plan that goes beyond two weeks.

  有一个变更计划和计划：交付计划永远不会完全准确。 没关系。 最初的目标是大致确定资源需求(团队，预算，进度，供应商等)。 通常，它应该描述您的路线，时间表和状态，以便您可以查看自己是否在进行中并与依赖于计划的其他团队保持一致。 这种计划与现阶段的日常任务无关，而是针对较低级别的计划，例如sprint计划。 根据对工作和绩效的了解不断改进它。 该计划不应是静态的。 始终将迭代，反馈和改进时间纳入计划。 这可以与SCRUM敏捷方法或更简单的看板工作流程一起使用，因此无需放弃这些方法的价值，同时仍可以制定超过两周的计划。

• Continuous Governance & Continuous Feedback: Essential to the ongoing development of the design & solution is a close relationship between the architect and the delivery team. This comes in the form of support and guidance to clarify and explain the design, as well as a demonstration of the implementation to meet that design. Don’t forget the architect is a key stakeholder with sign-off authority. If the delivery does not match the design there is either a failure in communication or a delinquent team. This process needs to be done regularly and often to avoid last-minute surprises. The architect must listen to the feedback of the delivery team to understand why they can’t implement the design or why the proposed solution is better (delivery teams have great ideas too). In practice, a weak architect will fail to make this work, as will a delinquent delivery team.

  持续的治理和持续的反馈：对于设计和解决方案的持续开发至关重要的是架构师与交付团队之间的密切关系。 这以澄清和解释设计的支持和指导的形式，以及为实现该设计而进行的演示。 别忘了建筑师是具有批准权限的关键利益相关者。 如果交货与设计不符，则可能是沟通失败或团队欠佳。 此过程需要定期且经常执行，以避免最后一刻的意外。 架构师必须听取交付团队的反馈，以了解为什么他们不能实现设计或为什么建议的解决方案更好(交付团队也有出色的想法)。 在实践中，软弱的架构师和拖延的交付团队也将无法完成这项工作。

• Work in Parallel Streams: The design stream has a lot of work upfront, which gradually tails off as the implementation becomes more concrete. The implementation stream should not start until the big picture architecture is done and you have a few candidate component designs, but once it starts with a few PoCs it can begin to ramp-up to full capacity. The big picture design scopes the ‘elements’ that need delivering and is used to form the plan’s sequence of design deep dives, PoCs, and development/build/test/etc.

  在并行流中工作：设计流的前期工作很多，随着实现变得更加具体，这些工作会逐渐减少。 在完成总体架构并拥有一些候选组件设计之前，不应该开始实施流程，但是一旦它以一些PoC开始，它就可以开始逐步提升到最大容量。 总体设计涵盖了需要交付的“要素”，并用于形成计划的设计顺序，包括深潜，PoC和开发/构建/测试/等。

• Platform First: An often overlooked, but very effective way of delivering quickly and iteratively to a consistent, well thought out design over your projects with minimal per project overhead, is to create a platform first, then implement your projects on it. If you start every project from scratch with new ideas, designs, tools, frameworks, methods, techniques, patterns, etc., then you will have an ongoing battle in every single project to figure all of that complexity out. You will either have to wait for the (much bigger) big design upfront or feel the pain of designing as you go. Both will be undesirably expensive and time-consuming. Don’t do that. Build a platform or framework or service that has done all that difficult thinking work upfront, and produced a ‘product’-like solution that you can adopt just as you would install a tool from a commercial vendor, except this is precisely tailored to what you need for your environment. This needs to be properly productised though — don’t attempt to throw some code together and call it a product: you need a path to live, you need build and test automation, you need designer/developer/operator/support manuals and documentation, and even a service wrapper. It needs to be truly ready to use, and for all the use cases needed for your projects. Don’t be tempted to do this as part of the first project. It is a project in its own right or, more accurately, it will be an ongoing concern for a team for a long time — new features, maintenance, support, etc. — so create a dedicated organisation to manage it. Think of them as an internal supplier to other teams/projects.

  平台优先：一种通常被忽略但非常有效的方法，可以以最小的每个项目开销快速，迭代地为您的项目提供一致，周到的设计，首先创建一个平台，然后在其上实施项目。 如果您从头开始每个项目时都采用新的想法，设计，工具，框架，方法，技术，模式等，那么您将在每个项目中进行不懈的战斗以弄清所有这些复杂性。 您将不得不等待(更大)的大型设计，或者在进行过程中感到设计的痛苦。 两者都将是不希望的昂贵和费时的。 不要那样做建立一个平台，框架或服务，该平台或框架已经完成了所有艰苦的思考工作，并产生了类似于“产品”的解决方案，您可以像安装商业供应商的工具一样采用该解决方案，除非这完全适合您的需求需要您的环境。 不过，这需要适当地进行生产-不要尝试将一些代码放在一起并称其为产品：您需要一条生存之路，需要构建和测试自动化，需要设计人员/开发人员/操作员/支持手册和文档，甚至是服务包装器。 它需要真正准备好使用，并且适合项目所需的所有用例。 不要在第一个项目中尝试这样做。 它本身就是一个项目，或者更准确地说，它将是一个团队长期以来一直关注的问题-新功能，维护，支持等-因此创建一个专门的组织来对其进行管理。 将它们视为其他团队/项目的内部供应商。

最后的几点思考 (A few final thoughts)

Sound-bite strategies: they all ‘sound’ great, but even if there are some nuggets of wisdom that went into creating them, they usually hide the messy, complicated reality. This leads the inexperienced down difficult paths. Be careful in how you use them: be inspired but don’t apply until you have worked out the practical implications for yourself.

咬合策略：它们都“听起来”很棒，但是即使创造了一些智慧，它们也通常隐藏了混乱而复杂的现实。 这导致缺乏经验的人走上艰难的道路。 在使用它们时要小心：要有所启发，但要先弄清楚对自己的实际影响，然后再应用。

Practical theory: Despite valuing the designing and strategising sides of my skillset I also appreciate my pragmatic side and believe the practical reality to be a strong creative driver for the theoretical, as well as the theoretical being an essential shaper of the possible realities. Don’t underestimate either.

实用理论：尽管珍惜技能集的设计和策略方面，但我也赞赏我的务实方面，并相信实用现实是理论的强大创造力，而理论是可能的现实的塑造者。 也不要小看。

Bridging the gap: There is a disconnect between the thinkers and the doers, enterprise architects and delivery teams, dreamers and pragmatists, ‘business people’ and ‘techies’. These gaps appear everywhere: within teams and between them. Bridging these gaps is key to making enterprise systems coherent (and your organisation efficient). It is not easy, and joined-up thinking is rare. Most fail at the first hurdle. Without being joined-up, communication breaks down, and teams (and the systems they design, build, run) start to diverge and begin the deadly spiral into complexity.

弥合差距：思想家与行动者，企业架构师和交付团队，梦想家与实用主义者，“商人”与“技术人员”之间存在着脱节。 这些差距无处不在：团队内部以及团队之间。 弥合这些差距是使企业系统保持一致(并使您的组织高效)的关键。 这并不容易，而且很少有联合思考。 大多数人一开始就失败了。 如果没有加入，沟通就会中断，团队(以及他们设计，构建，运行的系统)开始分化，并开始致命的螺旋式发展，变成复杂性。

Note: There are people, cultural, and behavioural challenges to address here too, though this is a topic for another day.

注意：尽管这是另一天的话题，但在这里也要解决人员，文化和行为上的挑战。

I will wrap up with a few observations:

我将总结一些观察结果：

• Balance thinking vs doing: too much or too little of either is bad

  平衡思考与做事：太多或太少都是不好的

• Taking time for preparation is an essential strategy for success.

  花时间准备是成功的重要策略。

• We are still very immature as an industry.

  作为一个行业，我们仍然很不成熟。

• There’s a lack of joined-up architecture: we are siloed at every turn.

  缺少联合的体系结构：我们无处不在。

• We need to balance the structured vs the creative natures of our work.

  我们需要平衡工作的结构性和创造性。

Ultimately, it is hard to build digital enterprises, but taking the time upfront to properly think through the approach and how all the bits fit together will make a significant difference to the success and quality of what you deliver.

最终，建立数字企业很困难，但是花些时间预先仔细考虑该方法以及各个方面如何融合在一起，将对您交付产品的成功和质量产生重大影响。

You can read more on the EnterpriseCore Blog or sign-up for one of the first copies of my upcoming book Mastering Digital: How technology leaders, architects, and engineers are building digital enterprises of the future.

您可以在EnterpriseCore博客上阅读更多信息，或注册我即将发行的《精通数字技术》一书的第一本：技术领导者，架构师和工程师如何构建未来的数字企业。

翻译自: https://blog.enterprisecore.io/unpopular-opinion-you-need-a-big-upfront-design-76edbf138e2a

英文ppt结尾欢迎您的意见