Entries for March 2009

14358 Views
7 Likes
3 Comments

In this SOA article I would like to begin by defining what SOA is and what you need to know about it. In future articles, I will explore some of the challenges and benefits of SOA to the analyst community. Let’s start off with a definition of SOA. You can, of course, look at a number of definitions of SOA on the Web, but you will find them confusing and contradictory as there are a number of views on this ranging from SOA is everything, to SOA is just Web Services, neither of which is true.

47134 Views
29 Likes
6 Comments

Processes are the user interface to a solution – as such they are highly visible and a lot of project effort is focussed on process modelling. In fact, there is a perception in some quarters that Business Analysts just draw process models and this is all they do. However, process models (the drawings of processes) are only one facet of the specification of a process.

19100 Views
14 Likes
2 Comments

Have you ever thought the following thought while describing business processes? A decent percentage of the work business analysts (BAs) do is repetitive in nature. Business rules define the various subject matters, different businesses, or just differences in doing business. Just recently, I have again used a use case approach to a business process reengineering (BPR) problem. The aim was restructuring along natural business module borders, so that different applications (new and existing ones) can handle the business process more efficiently, more secure and within the right stakeholder's responsibilities. As almost always, documentation of the business processes had undergone aging as well.

135946 Views
74 Likes
37 Comments

Before starting, it is important to understand process mapping’s place in the larger context of business process improvement.  Improving your process typically starts with documenting how it works today, what we call the “as-is” process.

14484 Views
7 Likes
0 Comments

In this article, I'll be discussing some other requirements gathering methods that complement use case modeling and should be used to ensure your requirements gathering goes swimmingly.

In particular, I'll be mentioning storyboards, wireframes and prototypes.
I'll also cover what level of quality and detail you should adopt when applying these techniques.

15392 Views
16 Likes
1 Comments

Not unlike gardening, Enterprise Analysis takes very careful stock and consideration of the current state of your environment. By IIBA® definition, Enterprise Analysis is:

  • The identification of business opportunities
  • Development and maintenance of a business architecture
  • The determination of optimum project investment
     
10012 Views
1 Likes
0 Comments

In a large enterprise, communication is complex and full of red-tape; e-mails, conference calls, meetings on top of meetings, memos, document management portals, and so on.

Wouldn’t it be nice to find a single resource that has all the answers?

9054 Views
1 Likes
0 Comments

There are great shifts that happen in technology and culture. Sometimes they occur sequentially, as WWII created a need for advanced computing, and the PC forever changed the nature of work.

Sometimes they happen concurrently, where pressures, both positive and negative, take place in tandem. We are in such a time of change now, with great crises and great opportunities for organizations and the people who love them. One of these challenges is the failure of Enterprise, Business and Technical architecture.

Why do the Three Stooges so often stumble and fail?

30821 Views
17 Likes
5 Comments

When ModernAnalyst asked me to propose an article for their issue on Enterprise Architecture, I thought about the question framework developed by John Zachman, that provides the basic building blocks of that practice.  The primary function of a Business Analyst is to ask questions that uncover requirements then to document those requirements so they may be developed into a useful, useable system.

16578 Views
40 Likes
6 Comments

As budgets tighten and organizations continue trying to achieve return on investment faster, cheaper and with better results, they are trying to create and evolve their overall enterprise architecture.

4834 Views
0 Likes
0 Comments

There appears to be a gross misunderstanding about Architecture, particularly in the information technology community. Many people seem to think that an implementation, an end result, is Architecture. To use an Architecture and Construction example, many people think that the Roman Coliseum is Architecture.

The Roman Coliseum is NOT Architecture. The Roman Coliseum is the RESULT of Architecture. The RESULT of Architecture is an instance of Architecture, an implementation. In the end result, the implementation, you can see an instantiation of the Architect’s Architecture. If an Architect had not created the descriptive representations (the Architecture) of the Roman Coliseum, they could not have built the Roman Coliseum. They couldn’t have even ordered the stones they required in order to build the Coliseum without the Coliseum Architecture which had to be created long before the Coliseum was constructed.

Architecture is the set of descriptive representations that are required in order to create an object. If you can’t describe it, you can’t create it. Also, if you ever want to change the object you created, Architecture constitutes the baseline for changing the object once it is created, that is, it is the baseline for changing the object IF you retain the descriptive representations used in its creation and IF you ensure that the descriptive representations are always maintained consistent with the instantiation.

If the object you are trying to create is so simple that you can see it in its entirety at a glance and remember how all of its components fit together at excruciating level of detail all at one time, you don’t need Architecture. You can "wing it" and see if it works. It is only when the object you are trying to create is complex to the extent that you can’t see and remember all the details of the implementation at once, and only when you want to accommodate on-going change to the instantiated object, that Architecture is IMPERATIVE. Once again, without Architecture, you are not going to be able to create an object of any complexity and you won’t be able to change it (that is, change it in minimum time, with minimum disruption and minimum cost).

 

So, the question is, what constitutes the set of descriptive representations relevant for describing an object such that you can create it and change it with minimum time, disruption and cost?

Author: John A. Zachman

4394 Views
0 Likes
0 Comments

Two years ago, some of my friends pressed me intensely to be more definitive about the Framework concepts. Even though, I had written “The Book”, they were specifically asking me for definitions of the entities that comprise the metamodel of Row 2 of the Enterprise Framework. It has taken me and a team of dedicated folks two years, however we have progressed far beyond the original requirement.

We have produced descriptions, not only of the entities of Row 2 of the Enterprise Framework, but also we have definitions of the entities of Row 1, Row 2, Row 3, Row 4, Row 5 and Row 6 of the Enterprise Framework plus descriptions for the Product Framework (where I learned about the Framework classification in the first place), for the Profession Framework (that I used to call the I/S Framework, the “meta Framework” relative to the Enterprise Framework) and for the Zachman Classification Framework (the Framework classification for all Frameworks).

This work is particularly significant at this point in time for several reasons.

Author: John A. Zachman





Latest Articles

What happens when the BA and UX worlds collide?
Aug 18, 2019
1 Comments
Are you a Business Analyst (BA) wondering what User Experience (UX) Design is all about and how your involvement in a design project is likely to impa...

Copyright 2006-2019 by Modern Analyst Media LLC