It is the process of monitoring the status of the project to update the project schedule and managing changes to the schedule baseline.
The key benefit: the schedule baseline is maintained throughout the project.
Frequency: throughout the project.
Process/ Assets Group
Input
The process
Output
Process / Assets Group
Project Management Plan
Schedule management plan
6.6 Control Schedule
Work performance information
4.5 Monitor and Control Project Work
Schedule baseline
Change Request
4.6 Perform Integrated Change Control
Scope baseline
Schedule management plan
Project Management Plan
Performance measurement baseline
Schedule baseline
Project Documents
Lesson learned register
Cost baseline
Project calendars
Performance measurement baseline
Project schedule
Schedule forecast
Project Documents
Resource calendars
Assumption log
Schedule data
Basis of estimates
4.3 Direct and Manage Project Work
Work performance data
Lesson learned register
Enterprise / Organization
Organizational process assets
Project schedule
Resource calendars
Risk register
Schedule data
The process concerns with:
Determining the current status of the project schedule,
Influencing the factors that create schedule changes,
Reconsidering necessary schedule reserves,
Determining if the project schedule has changed,
Managing the actual changes as they occur.
For agile approach:
Determining the current status of the project schedule by comparing the total amount of work delivered and accepted against the estimates of work completed for the elapsed time cycle;
Conducting retrospectives for correcting processes and improving, if required;
Reprioritizing the remaining work plan (backlog);
Determining the rate at which the deliverables are produced, validated, and accepted (velocity) in the given time per iteration;
Determining that the project schedule has changed;
Managing the actual changes as they occur.
For contractual work the milestones are controlled. Scheduled status reviews and walkthroughs should be done to verify the contractor reports.
6.6.1 Inputs
6.6.1.1 Project Management Plan
Includes:
Schedule management plan. Frequency to update, reserve usage, how to control;
Schedule baseline. To compare actual with baseline.
Earned value analysis. To assess the magnitude of variation to the original schedule baseline;
Iteration burndown chart. To track the work remaining to be completed in the iteration backlog. Variance with an ideal burndown (diagonal line) is analyzed. A forecast trend line is used to predict the likely variance at iteration completion.
Performance reviews. To measure, compare, analyze schedule performance against the baseline: actual start and finish dates, percent complete, remaining duration for work in progress.
Trend analysis. To analyze performance over time.
Variance analysis. Analysis of variances in planned values versus actual for start/finish dates, duration, float. Also cause, degree, future implications.
What-if scenario analysis.
6.6.2.2 Critical Path Method
Progress along the critical path -> schedule status.
6.6.2.3 Project Management Information System (PMIS)
Track planned dates versus actual dates.
6.6.2.4 Resource Optimization
6.6.2.5 Leads and Lags
Adjusting leads and lags to find way to bring project activities into alignment with the plan.
6.6.2.6 Schedule Compression
6.6.3 Outputs
6.6.3.1 Work Performance Information
6.6.3.2 Schedule Forecasts
Earned value performance indicators,
Schedule reserve information.
6.6.3.3 Change Requests
Schedule variance analysis/progress reports reviews/performance measures/modification of the project scope/modification of project schedule => change requests.
6.6.3.4 Project Management Plan Updates
Includes:
Schedule management plan.
Schedule baseline. Changes in project scope, resources, activity duration, results of schedule compression, performance issues.
It concerns with the cost of the resources needed to complete project activities.
It also should consider the effect of project decisions on the cost of using, maintaining, supporting the product, service, or result of the project.
Project costs can be measured in different ways and at different times. In some organizations product performance is calculated outside the project, in others - in the project scope. Is last case project will include additional processes and techniques.
Trends and Emerging Practices
Expansion of earned value management (EVM) to include the concept of earned schedule (ES).
ES is an extension of the theory and practice of EVM.
Tailoring Considerations
Considerations:
Knowledge management. Formal knowledge management in the organization and financial database repository.
Estimating and budgeting. Formal/Informal cost estimating/budgeting policies, procedures, guidelines.
Earned value management.
Use of agile approach.
Governance. Formal/informal audit and governance policies, procedures, guidelines.
Considerations for Agile/Adaptive Environment
Frequent changes -> no sense in detail cost calculations -> lightweight estimation methods. Detailed estimates are used for short-term planning horizons.
The process of analyzing activity sequences, durations, resource requirements, and schedule constraints to create a schedule model for project execution and monitoring and controlling.
The key benefit -> it generates a schedule model with planned dates for completing project activities.
Frequency: throughout the project.
Process
Input
The process
Output
Process
Project Management Plan
Schedule management plan
6.5 Develop Schedule
Schedule baseline
Project Management Plan
Scope baseline
Schedule management plan
Project Documents
Activity attributes
Cost baseline
Activity list
Change requests
4.6 Perform Integrated Change Control
Assumption log
Project schedule
Project Documents
Basis of estimates
Schedule data
Duration estimates
Project calendars
Lesson learned register
Activity attributies
Milestone list
Assumption log
Project schedule network diagrams
Duration estimates
Project team assignments
Lesson learned register
Resource calendars
Resource requirements
Resource requirements
Risk register
Risk register
12.2 Conduct Procurements
Agreements
Enterprise/Organization
Enterprise environment factors
Organizational process assets
The schedule model is used to determine the planned start and finish dates for project activities and milestones based on the best available information.
Key process steps:
Define the project milestones,
Identify and sequence activities,
Estimate durations,
Review staff assigned activities,
Get staff confirmation that the start and finish dates present no conflict with resource calendars and availability,
Analyze schedule for logical relationships,
Level resources,
Approve and baseline schedule.
6.5.1 Inputs
6.5.1.1 Project Management Plan
Include:
Schedule management plan. (The scheduling method and tool to create the schedule).
Scope baseline. The scope statement, WBS, WBS dictionary.
6.5.1.2 Project Documents
Include:
Activity attributes.
Activity list.
Assumption log.
Basis of estimates.
Duration estimates.
Lesson learned.
Milestone list.
Project schedule network diagrams.
Project team assignments.
Resource calendars.
Resource requirements.
Risk register.
6.5.1.3 Agreements
Contractual requirements to the project schedule.
6.5.1.4 Enterprise Environmental Factors
Government or industry standards,
Communication channels.
6.5.1.5 Organizational Process Assets
Include:
Scheduling methodology containing the policies governing schedule model development and maintenance,
Project calendar.
6.5.2 Tools and Techniques
6.5.2.1 Schedule Network Analysis
It is the overarching technique used to generate the project schedule model and employs several other techniques:
Critical path method,
Resource optimization techniques,
Modeling techniques.
Includes:
Assessing the need to aggregate schedule reserves to reduce the probability of a schedule slip when multiple paths converge at a single point in time or when multiple paths diverge from a single point in time, to reduce the probability of a schedule slip.
Reviewing the network to see if the critical path has high-risk activities or long lead items that would necessitate use of schedule reserves or the implementation of risk responses.
This technique is an iterative procedure until an acceptable model will be developed.
6.5.2.2 Critical Path Method
It is used to estimate the minimum project duration and determine the amount of schedule flexibility on the logical network paths within the schedule model. Calculation is executed without regard for any resource limitations by performing back and fro pass.
The critical path - the longest path through a project, which defines the shortest possible project duration.
The total float/schedule flexibility - the amount of time that a schedule activity can be delayed or extended from its early start without delaying the project finish date or violating a schedule constraint. The negative float is calculated when a backward schedule calculation is performed and (once more) it means that the project is late beyond the defined time term.
Critical path drag - the amount of time that an activity or constraint on the critical path is adding to the project duration. Alternatively, it is the maximum amount of time that one can shorten the activity before it is no longer on the critical path or before its duration becomes zero.
Steps:
Calculates the longest path of planned activities to logical end points or to the end of the project - critical path. The total float for the path = 0. Negative float - the project execution is beyond the final project term.
Calculates the earliest and latest that each activity can start and finish without making the project longer (determine "total float").
The activities on the non-critical path may moved in time inside the total float period.
6.5.2.3 Resource Optimization
The techniques is used to adjust the start and finish dates of activities to adjust planned resource use to be equal to or less than resource availability. A list:
Resource leveling or resource constrained scheduling (RCS) . Start and finish dates are adjusted based on resource constraints with the goal of balancing the demand for resource with the available supply. The technique can be used when shared or critically required resources are available only at certain times or in limited quantities, or are over-allocated (a resource has been assigned to two or more activities during the same time period), or there is a need to keep resource usage at a constant level. Resource leveling usually causes the original critical path to change.
Resource smoothing. A technique to adjust the activities of a schedule model such that the requirements for resources on the project do not exceed certain predefined resource limits. The project critical path is not changed and the completion date may not be delayed. The technique use free and total float of activities. It may not be able to optimize all resources. There is need to avoid any delay in activity as it may affect critical path.
The following are a few differences between resource leveling and resource smoothing:
In resource leveling the project end date may change while in smoothing it does not change.
In resource leveling the critical path changes (generally increases) while in resource smoothing it does not, and activities can be delayed within their float.
Generally resource smoothing is usually performed after the resource leveling.
In resource leveling resources are the main constraint while in resource smoothing project end date is a constraint.
Resource leveling is used when resources are under or over allocated. Resource smoothing is used when resources are unevenly allocated.
Resource leveling can be applied to activities on the critical path while in resource smoothing you do not touch activities on the critical path.
6.5.2.4 Data Analysis
Include:
What-if scenario analysis. The process of evaluating scenarios in order to predict their effect, positive or negative, on project objectives. A schedule network analysis is performed using the schedule to compute the different scenarios (delaying a major component delivery, introducing external factors, such a change in a permit process). The outcome of the analysis can be used to assess the feasibility of the project schedule and prepare reserves and response plans to address the problems.
Simulation. It models the combined effects of individual project risks and other sources of uncertainty to evaluate their potential impact on the project objects.
Monte Carlo analysis. Inputs for the model are using probability distributions (are generated by some probability distribution). The model outcomes are used to build probability distribution for project goals.
6.5.2.5 Leads and Lags
6.5.2.6 Schedule Compression
Techniques are used to shorten or accelerate the schedule duration without reducing the project scope in order to meet schedule constraints, imposed dates, or other schedule objectives. The techniques used for the critical path which total float is zero (or negative if the project delays). Includes:
Crashing. Shortens the schedule duration by adding resources. Applied to the critical path. Crashing may bring additional risks.
Fast tracking. Sequence of activities -> parallel (or portion of tasks). May result in rework and risks, additional costs.
6.5.2.7 Project Management Information System (PMIS)
Includes scheduling software -> generates start and finish dates based on the inputs of activities, network diagrams, resources, and activity durations.
6.5.2.8 Agile Release Planning
A high-level summary timeline of the release schedule (3-6 months) based on the product road-map and the product vision. The planning also determines the number of iterations or sprints in the release -> to decide how much needs to be developed and how long it will to have a releasable product based on business goals, dependencies, and impediments.
6.5.3 Outputs
6.5.3.1 Schedule Baseline
The approved version of a schedule model that can be changed only through formal change control procedures and is used as a basis for comparison to actual results. It is accepted and approved by appropriate stakeholders with baseline start dates and baseline finish dates. During monitoring and controlling variances are calculated: baseline against actual dates.
6.5.3.2 Project Schedule
The output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources. At a minimum: start/finish for each activity.
Target model - with a defined target start and target finish for each activity.
Summary, milestone, detail forms of schedule.
Presentation forms:
Bar charts (Gantt charts). Activities listed on the vertical axis, dates are shown on the horizontal axis, activity durations are shown as horizontal bars places according to start and finish dates. Additional information can be presented.
Milestone charts. Similar to bar chart, but only main events are presented.
Project schedule network diagrams.
The activity-on-node diagram format showing activities and relationships without a time scale (also referred as a pure logic diagram).
Presented in a time-scaled schedule network diagram format (also called a logic bar chart). This presentation shows project network logic and the project's critical path schedule activities.
A time-scaled logic diagram. Bars represent the duration of activities with logical relationships.
6.5.3.3 Schedule Data
The collection of information for describing and controlling the schedule:
Schedule milestones,
Schedule activities,
Activity attributes,
Documentation of all identified assumptions and constraints.
Additional data:
Resource requirements by time period, often as resource histogram;
Alternative schedule: best-case/worst-case, resource-leveled/not leveled;
Applied schedule reserves.
Could include:
Resource histograms,
Cash-flow projections,
Order and delivery schedules,
Other.
6.5.3.4 Project Calendars
It identifies working days and shifts available for scheduling activities. Available/not available periods of time. Several calendars may be used.
Действия по укреплению команды могут варьироваться от пятиминутного пункта в повестке дня совещания по оценке текущего состояния до специальных тренингов с участием профессионалов с целью улучшения межличностных отношений среди членов команды. Цель выполнения действий по укреплению команды – помочь отдельным ее членам эффективно работать друг с другом. Стратегии укрепления команды особенно ценны, когда члены команды расположены далеко друг от друга и не имеют возможности личного общения. Неформальное общение и соответствующие мероприятия могут помочь укрепить чувство доверия и установить хорошие рабочие взаимоотношения.
Одним из наиболее важных навыков при развитии среды команды является умение рассматривать проблемы команды проекта и обсуждать их как командные проблемы. Необходимо стимулировать всю команду для совместного разрешения данных проблем. Для формирования эффективных команд проектов менеджеры проектов должны заручиться поддержкой высшего руководства и приверженностью членов команд, назначать соответствующие поощрения и вознаграждения, формировать своеобразие команды, эффективно улаживать конфликты, укреплять доверие и создавать условия для открытого общения между членами команды и, кроме того, осуществлять адекватное руководство командой.
Укрепление команды, как постоянный процесс, является критически важным для успеха проекта. Хотя укрепление команды особенно принципиально в начале проекта, данный процесс никогда не заканчивается. Изменения в окружающей среде проекта неизбежны, и для эффективного управления ими должны прилагаться постоянные или периодические усилия по укреплению команды. Менеджер проекта должен постоянно контролировать действия членов команды и их производительность, чтобы определять, требуются ли какие-либо действия для предотвращения или устранения различных проблем команды.
Одна из теорий утверждает, что существует пять стадий развития, через которые могут проходить команды. Обычно эти стадии наступают по порядку. Однако нередко команда может «застрять» на определенной стадии или вернуться на более раннюю. Кроме того, в проектах, члены команд которых работали раньше вместе, определенные стадии могут быть пропущены.
Формирование. На данной стадии команда собирается вместе и узнает о проекте и о своих формальных ролях и ответственности в нем. Члены команды на данной фазе, как правило, независимы друг от друга и не особенно открыты. Для получения подробной информации см. Tuckman ladder of team development.
Шторм. В течение данной стадии команда начинает изучать работы по проекту, технические решения и подход к управлению проектом. Если члены команды не настроены на сотрудничество и не открыты различным идеям и перспективам, обстановка может стать деструктивной.
Урегулирование. На стадии урегулирования члены команды начинают работать вместе и подстраивают свои рабочие привычки и модели поведения так, чтобы содействовать командной работе. Члены команды начинают доверять друг другу.
Результативность. Команды, достигшие стадии результативности, функционируют как хорошо организованное подразделение. Они независимы и спокойно и эффективно решают проблемы.
Завершение. На этой стадии команда завершает работу и переходит к следующему проекту.
Длительность каждой конкретной стадии зависит от динамики, численного состава и руководства команды. Менеджеры проектов должны хорошо представлять себе динамику развития команды, чтобы способствовать эффективному прохождению членами команды всех стадий.
The process of estimating the number of work periods needed to complete individual activities with estimated resources.
The key benefit – it provides the amount of time each activity will take to complete.
Frequency: throughout the project.
Process name/ Enterprise Process Asset Group
Input
Process
Output
Process name/ Enterprise Process Asset Group
Project Management Plan
Schedule management plan
6.4 Estimate Activity Durations
Duration Estimates
Project Documents
Scope baseline
Basis of estimates
Project Documents
Activity attributes
Activity attributes
Project document updates
Activity list
Assumption log
Assumption Log
Lesson learned register
Lesson learned register
Milestone list
Project team assignments
Resource breakdown structure
Resource calendars
Resource requirements
Risk register
Enterprise environmental factors
Organizational process assets
Estimation of the amount of work effort + available resource (quantity and quality) estimation + project calendars + resource calendars -> approximate number of work periods (activity duration) .
Factors for consideration:
Law of diminishing returns. Effect of using the next unit of resource is lesser than using the previous unit.
Number of resources. Increasing the number of one resource not always reduce usage of others including time. Increased number of people leads to increased communications which lead to increased time to execute job.
Advances in technology.
Motivation of staff.
Student Syndrome – start to work before deadline;
Parkinson’s Law – work expands to fill the all available time.
6.4.1 Inputs
6.4.1.1 Project Management Plan
Used components:
Schedule management plan. The used method and accuracy level, other criteria to estimate durations.
Duration estimating databases, other reference data,
Productivity metrics,
Published commercial information,
Location of team member.
6.4.1.4 Organizational Process Assets
Include:
Historical duration information,
Project calendars,
Estimating policies,
Scheduling methodology,
Lesson learned repository.
6.4.2 Tools and Techniques
6.4.2.1 Expert Judgement
By individuals or groups by topics:
Schedule development, management and control;
Expertise in estimating;
Discipline or application knowledge.
6.4.2.2 Analogous Estimating
A technique for estimating the duration the duration or cost of an activity or a project using historical data from a similar activity or project. The activities / project should be analogous. For the duration it is taken actual duration. The method is frequently used when there is limited information about the project.
Less costly but less accurate.
6.4.2.3 Parametric Estimating
An algorithm is used to calculate cost or duration based on historical data and project parameters. A statistical relationship between historical data and other variables.
6.4.2.4 Three-Point Estimating
Defines an approximate range for an activity duration:
Most likely (tM). The estimate for the most likely variant of resource number, quality, availability and so on.
Optimistic (tO). Best-case scenario.
Pessimistic (tP). The worst-case scenario.
Expected (tE). tE = (tO+tM+tP)/3. Used when there is insufficient historical data or when using expert judgmental data.
6.4.2.5 Bottom-up Estimating
Estimating by aggregating the estimates of the lower-level components of the WBS.
The activity is decomposed to the needed level of detail to get a confident detail estimations.
6.4.2.6 Data Analysis
Alternatives Analysis. Used to compare:
Various levels of resource capability or skills;
Scheduling compression techniques;
Different tools;
Decisions on make/rent/buy resources.
Reserve analysis. Used to determine the amount of contingency and management reserves needed for the project. Duration estimates may include contingency reserve (schedule reserves) for schedule uncertainty for the identified risks that are accepted. The contingency reserve may be a percentage or a fixed number of work periods. They may be aggregated. With more precise information on the project the reserve may be used, reduced, or eliminated. The reserves should be clearly documented.
Management reserve is allocated for management control purposes -> unforeseen work that is within the scope of project. not included into the schedule baseline, but it is part of the overall project duration requirements. Use of the reserve may require a change to the schedule baseline.
6.4.2.7 Decision Making
Voting.
6.4.2.8 Meeting
6.4.3 Outputs
6.4.3.1 Duration Estimates
Quantitative assessment of the likely number of time periods that required to complete an activity, a phase, or a project. They do not include any lags. They may include the range of possible results.
6.4.3.2 Basis of Estimates
How the estimates were derived. May include:
Documentation of the basis of the estimate,
Documentation of all assumptions made,
Documentation of any known constraints,
Indication of the range of possible estimates to indicate that the duration is estimated between a range of values,
Indication of the confidence level of the final estimate,
Documentation of individual project risks influencing this estimate.
В
результате разработки архитектуры предприятия появляются так называемые
продукты архитектуры: документы по описанию архитектуры, регламенты,
планы, инструкции и т.д., и т.п. И здесь прослеживается очень точная
аналогия с той же архитектурой в зодчестве. Но, если мы коснемся
процесса выработки архитектуры, то аналогия здесь и закончится.
Обычная
архитектура имеет дело с неживыми предметами. Кирпичи - они и в Африке
кирпичи, а бетон, хоть и меняет агрегатные состояния, но предсказуем.
Никакие чертежи, планы не могут изменить свойств кирпича. А вот
архитектура предприятия имеет дело с людьми, подразделениями,
организациями. Все они имеют свои цели, устремления, поведение, хоть и
на разных уровнях. И они меняют свое поведение/характеристики по мере
того, как меняется их понимание окружающей среды и их собственных целей.
Если я увижу, что в новой архитектуре нет места моему подразделению
(моей должности, организации, …), то очень легко предугадать, что мои
характеристики как работника подразделения очень и очень изменятся.
Точно так же изменятся характеристики всех участников жизни предприятия
на всех уровнях. Таким образом, мы пришли к тому, что продукты
разработки архитектуры предприятия носят очень и очень временный
характер. Как только они разработаны, нужно их менять, так как
предприятие уже изменилось даже в силу разработки этих же продуктов, не
говоря уже о внешнем воздействии. И так постоянно, пока предприятие
живо.
Если кирпичи и не изменяются в ходе разработки архитектуры здания, то рабочие даже очень.
В
связи с этой сложностью процесса разработки архитектуры существуют
разные подходы у организаций к архитектуры предприятия. Самые часто
встречающиеся:
Нет
документированной архитектуры вообще. Архитектура существует только в
голове управленческого персонала компании. Нельзя сказать, что это
плохо. Для частных предприятий, малых, - это даже хорошо. Есть экономия
на разработке архитектуры, а результат от ее использования не так уж и
велик. Количество сотрудников мало и архитектура может быть проговорена и
распространена без лишней бюрократии. Но для больших предприятий - это
беда. Не имея четкой основы для обсуждения, разные слои менеджмента
движутся с большими задержками. Наверху жалуются на “тупых” подчиненных,
которым всегда туго все доходит. Снизу жалуются на начальство, которое
“понапридумывает всякой чепухи”, а реальные проблемы не решаются;
Существует
документированная архитектура в виде когда-то созданных инструкций,
положений, регламентов, и т.д. Когда-то создали, и больше особо не
меняли. В результате документация осталась тоже где-то в прошлом, а
предприятие спотыкается о нее, с одной стороны стараясь приспособиться к
новой внешней среде, а с другой стороны начальство продолжает стараться
заставить подчиненных работать по инструкции. Это вариант, который
остался от старого прошлого, когда организации эволюционировали
медленно, так как все менялось медленно, когда цикл обновления
оборудования был 10 лет, а то и больше. Сейчас, когда цикл обновления
сократился до 3 лет, а программном обеспечении - так и вообще такое
впечатление, что непрерывно, такой подход уже применять очень и очень
тяжело. Лучше сказать, что невозможно. Кстати, нужно отметить, что в эту
категорию попадают и те разработки архитектуры предприятия, где
руководство и архитекторы не понимают ее природу. Создав кипу
документации, создатели успокаиваются и начинают заставлять предприятие
жить по этим инструкциям, не замечая, что их документация медленно, но
верно устаревает;
Архитектура
предприятия создается до мельчайших подробностей. В результате
получается многотомный продукт. И его уже нужно менять. А ресурсов на
поддержание такой детальной документации обычно нет. И ситуация
переходит в предыдущий вариант;
Правильный
вариант. Документация достаточно подробна, но и не тяжеловесна.
Разрабатывается на основе тесного общения всех заинтересованных лиц.
Будучи однажды разработанной, постоянно поддерживается в актуальном
состоянии, более того - на основе ее разработки формируются рабочие
документы, которые регулируют жизнь предприятия. Архитектура является
средством, а не самоцелью.
Как
видим, разработка архитектуры предприятия является также частью
искусства и умения архитектора. Как говорится: “все хорошо в меру”. Так
что в будущем нас ждет появление “лучших” и просто “хороших” практик,
как разрабатывать и жить с архитектурой предприятия. На данном этапе
такие хорошие практики распространяются с помощью методологий построения
архитектуры предприятия.
И
еще пара замечаний: для того, чтобы результат был более пресказуемым,
т.е. чтобы изменения самих участников процесса учитывались как можно
скорее, работу с архитектурой нужно проводить интерактивно. При этом
каждая итерация должна быть досаточно короткой.
Как и обычный продукт, архитектура разрабатывается в течение следующих этапов, шагов:
Для управления любой сложной системой, необходимо использовать ее архитектуру. Это относится и к такой сложной системе, как большая организация. Любое весомое изменение в структуре или процессах организации может привести не к повышению эффективности и оптимальности организации, а очень даже наоборот. А иногда и последующей смерти.
В масштабные изменения всегда вовлечена масса сотрудников. Все помнят, что Вавилонскую башню не смогли достроить, так как разные народы разговаривали на разных языках и их действия не могли хорошо синхронизировать. Поэтому при описании преобразований в организации нужно использовать один язык, который понимают все одинаково, как минимум на уровне руководителей среднего звена.
Основой такого языка является архитектура предприятия. Точно так же, как при строительстве здания архитектура задает одинаковое понимание, из чего должно состоять здание и как его строить, так и при строительстве организации архитектура предприятия позволяет задавать одинаковое понимание о текущем и о будущем состоянии.
Бурж Халиф, самое высокое здание на текущий момент. Невозможно представить, что такое здание было построено без описания архитектуры здания в чертежах и планах, которые соединили тысячи работников в единый организм. И невозможно представить, как удается управлять компаниями без подобных детальных чертежей. Может поэтому в странах СНГ один из самых низких уровней организованности?
Определение понятие архитектуры по стандарту ISO/IEC/IEEE FDIS 42010:2011:
Архитектура - это фундаментальные концепции или свойства системы в ее окружении, заключающиеся в ее элементах, взаимозависимостях, а также принципы ее конструкции и развития.
Как видно из определения, архитектура включает в себя как конструкцию, так и те факторы, которые влияют на ее развитие.
Архитектура создается для использования определенным кругом лиц. Такие лица называются заинтересованными, или, как один из аглоникаизмов, стейкхолдеры (те, которые держат отбивные :) ) - stakeholders. По определению стандарта IEEE заинтересованными лицами являются:
Заинтересованные лица - персоны, группы или целые организации (или классы таковых), которые интересуются системой, или кого таковая система затрагивает.
При этом “интересуются” и “затрагивает” - как в положительном, так и в отрицательном смысле этого слова. Может быть, что меня архитектура система и вообще не интересует, да и не нужна она мне вообще. Но если она меня затрагивает, например, после ее внедрения я буду работать в два раза больше/меньше, то я, получается, уже “заинтересованное лицо”.
