Создание единого информационного пространства: с чего начать.
Лично я не люблю термин "единое информационное пространство" -- как и любой другой термин, в котором есть слово "единый" (критерий любого "единства" обычно не лучше, чем в "Единой России") или "пространство". Как-то в начале 90-х меня какой-то юрист спросил, как я представляю себе "юридическое пространство" -- и долго смеялся над моими попытками объяснить случайно повторённый за кем-то термин. В начале 2003 о "едином юридическом пространстве" заговорил Европейский Союз -- как о географическом понятии. Кстати, единое юридическое пространство -- 533 упоминания на Яндексе, и отнюдь не только в смысле географического пространства. Единое информационное пространство -- 450тыс. упоминаний -- можно этот термин не любить, но он широко используется.
В описании метода "Инженерия справочных данных ISO 15926" (http://techinvestlab.ru/files/RefDataEng/RefDataEngr_ver_2_25feb11.doc) мы дали определение единому информационному пространству как совокупности хранилищ проектных данных, между которыми существует интеграция данных (т.е. возможность передачи данных без потерь по принципу "каждый с каждым", а не только "точка-точка" для тщательно отобранных пар). Если ваш CAD может обменяться нужными данными с вашей ERP, а они оба -- с вашей PLM, то поздравляем: вы обладатель того самого единого информационного пространства, ибо сумели провести интеграцию данных.
Для того, чтобы получить единое информационное пространство, нужно иметь его справочные данные -- шаблоны-"пустографки" для выражения проектных данных. Жизненный цикл справочных данных начинается с разбирательства с наличным "неединым" информационным пространством: разбирательством, какие данные в каких информационных системах присутствуют, и какие передачи данных необходимы. Этому соответствует стадия "1. выявление набора проектных данных" жизненного цикла справочных данных.
На этой стадии вы должны найти и задокументировать необходимые виды рабочих продуктов (терминология ISO 24744), которые являются информационными объектами (физические объекты, основным назначением которых является представление информации -- хранилища данных, распечатки, файлы на дисках и т.д. -- это терминология ISO 15926. По терминологии ISO 15289 такие рабочие продукты будут information items -- a separately identifiable body of information that is produced and stored for human use during a system or software life cycle), на которых передаются или экземплифицированы данные жизненного цикла. Нас интересуют такие данные жизненного цикла, которые вы ходите передавать из хранилища в хранилище -- формируя то самое "единое информационное пространство". В любом случае это было бы правильно сделать -- это полностью соответствует рекомендациям ISO 15288 и выполняется в рамках его практики Information Management, как указано в ISO 15289.
Дисциплина систематического документирования (можно даже сказать "моделирования") информационных систем предприятия -- это Enterprise Architecture (EA). Эта дисциплина отражает то, что информационные системы предприятия (говорят также "корпоративные информационные системы", КИС) являются частью предприятия, как целого -- и невозможно в них разобраться, если при этом не задокументировать (отмоделировать) также и всё предприятие в целом. Итого получается: в EA 90% занимает моделирование самого предприятия, и 10% остаётся на моделирование информационных систем.
Тут нужно бы процитировать почти весь постинг «Моделирование "процессов" в организации» (http://ailev.livejournal.com/904643.html), где я кратко характеризую языки архитектурного описания, архитектурные фреймворки, даю намёк на разные группы описаний предприятия и описываю разные понимания "процессов", которые можно обнаружить на предприятии.
Для того, чтобы подобраться к выявлению и документированию наборов данных, нужно понимать основное производство предприятия -- что производит это предприятие, какой жизненный цикл это предприятие обеспечивает, и тем самым дать ответ на вопрос "какой жизненный цикл обеспечиают информационные системы предприятия". Особо отметим, что речь тут идет о расширенном предприятии (т.е. фактически о группе независимых друг от друга юридических лиц, объединённых контрактами и занятых обеспечением одного жизненного цикла).
Это соответствует разделу "8. Mapping of information items to the life cycle" из ISO 15289:2006, но я далек от мысли о непосредственной применимости этой нормы как по форме записи (табличка входных и выходных данных мероприятия той или иной практики жизненного цикла системной инженерии), так и по содержанию (я вовсе не уверен, что организационные процедуры являются входными для описания жизненного цикла -- я бы делал ровно наоборот), Я также далёк от мысли посоветовать выполнение тамошней "Procedure for identifying information items and their contents" из Annex A этого стандарта. Но я совершенно согласен с мыслью о необходимости указания связей между информационными объектами и жизненным циклом как пререквизита для какой-то осмысленной работы с информационными объектами.
Тем самым мы должны разработать много справочных данных (метамоделей, "пустографок") для моделирования жизненного цикла и его информационных объектов:
а) выбрать язык и нотацию для рабочего продукта "модель жизненного цикла" (например, из предложенных в обзоре http://ailev.livejournal.com/917251.html).
б) выбрать язык и нотацию для рабочего продукта "модель информационных объектов".
в) выбрать язык и нотацию для рабочего продукта "модель информационных объектов в контексте жизненного цикла".
г) определить (то есть разработать определения_документов в смысле ISO 15926) какие информационные объекты (документы в смысле ISO 24744) мы должны разрабатывать (т.е. наполнять данными моделирования) для отражения (depict) моделей предыдущих пунктов (а, б и в).
Изо всех вариантов представления жизненного цикла наиболее подходящим является использование ситуационной инженерии методов с сочетании с описанием постепенно появляющихся частей моделей ЖЦ и информационных объектов в 4D-представлении ISO 15926:
-- в рамках одного формализма выразим не только жизненный цикл, но и его практики, а также необходимые рабочие продукты (в том числе включая описание языков и нотаций, а также используемых моделей и документов -- это есть в ISO 24744)
-- необходимая подробность описания специфических для данного моделирования рабочих продуктов (справочных данных -- "пустографок") может быть обеспечена использованием ISO 15926-моделирования.
-- 4D позволяет выразить в том числе и появление проектных данных в ходе инженерной разработки, и передачи проектных данных между хранилищами.
Конечно, эти "определения документов" для моделирования ЖЦ+информ.объектов необходимо конкретизировать до уровня конкретного используемого языка и нотации плюс указания на инструментарий. Что-то мне подсказывает, что этим языком будет язык шаблонов ISO 15926, нотация будет табличной, а инструментарием -- Exel.
Этот набор "определений документов" готовится один раз (т.е. может быть найден в praxos -- когда мы его разработаем). Вполне можно говорить, что это часть "архитектурного фреймворка" для описываемой в PraxOS корпоративной архитектуры. Равным образом можно говорить, что это часть каталога компонент метода работы предприятия (ибо это часть описания того, как работает предприятие, продвигая свои целевые системы по их жизненному циклу). Равным образом можно говорить, что это справочные данные для инженерии справочных данных.
После чего -- идём на предприятие, и проводим обследование, заполняя полученные "пустографки"-документы данными моделирования жизненного цикла и информационных объектов. Ну, или никуда не идём (если точно знаем, что на предприятии ничего не найдём: например, речь идет о каком-то новом жизненном цикле, для которого еще не существует никаких информационных объектов, или тех информационных объектов, которые можно было бы взять в качестве прототипа/образца) и придумываем все эти модели и определения документов "из головы".
Дальше -- смотрим на полученные диаграммы ЖЦ+информационных объектов, определяем высокоприоритетные обмены данных и проводим итерации "Инженерии справочных данных ISO 15926". Через некоторое (наверняка немаленькое) время выполнения этих итераций (внимание! примерение ISO 15926 -- это деятельность по типу "снизу вверх", много-много коротких итераций, а не один большой проход) золотой ключик от "единого информационного пространства" у нас в кармане.
В описании метода "Инженерия справочных данных ISO 15926" (http://techinvestlab.ru/files/RefDataEng/RefDataEngr_ver_2_25feb11.doc) мы дали определение единому информационному пространству как совокупности хранилищ проектных данных, между которыми существует интеграция данных (т.е. возможность передачи данных без потерь по принципу "каждый с каждым", а не только "точка-точка" для тщательно отобранных пар). Если ваш CAD может обменяться нужными данными с вашей ERP, а они оба -- с вашей PLM, то поздравляем: вы обладатель того самого единого информационного пространства, ибо сумели провести интеграцию данных.
Для того, чтобы получить единое информационное пространство, нужно иметь его справочные данные -- шаблоны-"пустографки" для выражения проектных данных. Жизненный цикл справочных данных начинается с разбирательства с наличным "неединым" информационным пространством: разбирательством, какие данные в каких информационных системах присутствуют, и какие передачи данных необходимы. Этому соответствует стадия "1. выявление набора проектных данных" жизненного цикла справочных данных.
На этой стадии вы должны найти и задокументировать необходимые виды рабочих продуктов (терминология ISO 24744), которые являются информационными объектами (физические объекты, основным назначением которых является представление информации -- хранилища данных, распечатки, файлы на дисках и т.д. -- это терминология ISO 15926. По терминологии ISO 15289 такие рабочие продукты будут information items -- a separately identifiable body of information that is produced and stored for human use during a system or software life cycle), на которых передаются или экземплифицированы данные жизненного цикла. Нас интересуют такие данные жизненного цикла, которые вы ходите передавать из хранилища в хранилище -- формируя то самое "единое информационное пространство". В любом случае это было бы правильно сделать -- это полностью соответствует рекомендациям ISO 15288 и выполняется в рамках его практики Information Management, как указано в ISO 15289.
Дисциплина систематического документирования (можно даже сказать "моделирования") информационных систем предприятия -- это Enterprise Architecture (EA). Эта дисциплина отражает то, что информационные системы предприятия (говорят также "корпоративные информационные системы", КИС) являются частью предприятия, как целого -- и невозможно в них разобраться, если при этом не задокументировать (отмоделировать) также и всё предприятие в целом. Итого получается: в EA 90% занимает моделирование самого предприятия, и 10% остаётся на моделирование информационных систем.
Тут нужно бы процитировать почти весь постинг «Моделирование "процессов" в организации» (http://ailev.livejournal.com/904643.html), где я кратко характеризую языки архитектурного описания, архитектурные фреймворки, даю намёк на разные группы описаний предприятия и описываю разные понимания "процессов", которые можно обнаружить на предприятии.
Для того, чтобы подобраться к выявлению и документированию наборов данных, нужно понимать основное производство предприятия -- что производит это предприятие, какой жизненный цикл это предприятие обеспечивает, и тем самым дать ответ на вопрос "какой жизненный цикл обеспечиают информационные системы предприятия". Особо отметим, что речь тут идет о расширенном предприятии (т.е. фактически о группе независимых друг от друга юридических лиц, объединённых контрактами и занятых обеспечением одного жизненного цикла).
Это соответствует разделу "8. Mapping of information items to the life cycle" из ISO 15289:2006, но я далек от мысли о непосредственной применимости этой нормы как по форме записи (табличка входных и выходных данных мероприятия той или иной практики жизненного цикла системной инженерии), так и по содержанию (я вовсе не уверен, что организационные процедуры являются входными для описания жизненного цикла -- я бы делал ровно наоборот), Я также далёк от мысли посоветовать выполнение тамошней "Procedure for identifying information items and their contents" из Annex A этого стандарта. Но я совершенно согласен с мыслью о необходимости указания связей между информационными объектами и жизненным циклом как пререквизита для какой-то осмысленной работы с информационными объектами.
Тем самым мы должны разработать много справочных данных (метамоделей, "пустографок") для моделирования жизненного цикла и его информационных объектов:
а) выбрать язык и нотацию для рабочего продукта "модель жизненного цикла" (например, из предложенных в обзоре http://ailev.livejournal.com/917251.html).
б) выбрать язык и нотацию для рабочего продукта "модель информационных объектов".
в) выбрать язык и нотацию для рабочего продукта "модель информационных объектов в контексте жизненного цикла".
г) определить (то есть разработать определения_документов в смысле ISO 15926) какие информационные объекты (документы в смысле ISO 24744) мы должны разрабатывать (т.е. наполнять данными моделирования) для отражения (depict) моделей предыдущих пунктов (а, б и в).
Изо всех вариантов представления жизненного цикла наиболее подходящим является использование ситуационной инженерии методов с сочетании с описанием постепенно появляющихся частей моделей ЖЦ и информационных объектов в 4D-представлении ISO 15926:
-- в рамках одного формализма выразим не только жизненный цикл, но и его практики, а также необходимые рабочие продукты (в том числе включая описание языков и нотаций, а также используемых моделей и документов -- это есть в ISO 24744)
-- необходимая подробность описания специфических для данного моделирования рабочих продуктов (справочных данных -- "пустографок") может быть обеспечена использованием ISO 15926-моделирования.
-- 4D позволяет выразить в том числе и появление проектных данных в ходе инженерной разработки, и передачи проектных данных между хранилищами.
Конечно, эти "определения документов" для моделирования ЖЦ+информ.объектов необходимо конкретизировать до уровня конкретного используемого языка и нотации плюс указания на инструментарий. Что-то мне подсказывает, что этим языком будет язык шаблонов ISO 15926, нотация будет табличной, а инструментарием -- Exel.
Этот набор "определений документов" готовится один раз (т.е. может быть найден в praxos -- когда мы его разработаем). Вполне можно говорить, что это часть "архитектурного фреймворка" для описываемой в PraxOS корпоративной архитектуры. Равным образом можно говорить, что это часть каталога компонент метода работы предприятия (ибо это часть описания того, как работает предприятие, продвигая свои целевые системы по их жизненному циклу). Равным образом можно говорить, что это справочные данные для инженерии справочных данных.
После чего -- идём на предприятие, и проводим обследование, заполняя полученные "пустографки"-документы данными моделирования жизненного цикла и информационных объектов. Ну, или никуда не идём (если точно знаем, что на предприятии ничего не найдём: например, речь идет о каком-то новом жизненном цикле, для которого еще не существует никаких информационных объектов, или тех информационных объектов, которые можно было бы взять в качестве прототипа/образца) и придумываем все эти модели и определения документов "из головы".
Дальше -- смотрим на полученные диаграммы ЖЦ+информационных объектов, определяем высокоприоритетные обмены данных и проводим итерации "Инженерии справочных данных ISO 15926". Через некоторое (наверняка немаленькое) время выполнения этих итераций (внимание! примерение ISO 15926 -- это деятельность по типу "снизу вверх", много-много коротких итераций, а не один большой проход) золотой ключик от "единого информационного пространства" у нас в кармане.