When the scope of a project is limited to a single application, I'm recommending on 2 phase approach.
In the first phase, I'm gathering the current status at the enterprise level. The point here is that I'll just to try to gather as much information as possible and not a comprehensive set of information as in EA. The end product here is the framework, "architecture patterns" that individual project may use, roadmap suggestions for currently ongoing projects, and "suggested" governance rules to the current and future projects. In the second phase, I'm selecting the pattern to use and customize. This will be the constraint to business services/processes. To those who are into research, what's I'm doing is deriving NFR from FR in use cases. Next, I'm creating a NFR implementation strategy which may weave cross-cutting NFR concerns into the FR. This may be done software-wise or hardware-wise in application or infrastructure layers. This way, FR and NFR are related in the use cases and FR and NFR implementation are separated. Thus, a change to FR or NFR implementation may be traced to corresponding use cases to find the impact and its range. Just got a new account. There goes my Christmas. H.Ozawa --- In [email protected], "Anne Thomas Manes" <atma...@...> wrote: > > I always recommend a "think big, take small steps" methodology. So I > concur with the "take one small step at a time" advice. But I find > that many organizations forget the "think big" part of the equation. > > Anne >
