Tuesday, April 17, 2007

IA: Enterprise Information Architecture

Enterprise Information Architecture had no meaning to me before the class I took at BYU. I had heard that it was very challenging and way over some students’ heads. Knowing this, I decided I was going to be one of the few people that grasped the concepts that would be taught in the course, and that I would make a big effort in doing whatever extra research I had to in order to better understand the material presented in class.

EIA basically deals with the way an enterprise collects, manages, and monitors the enormous amounts of data that it processes.

The main areas of the course consisted of:

  • SOA
    • Web services- introduction to SOAP, WSDL
  • MDA
  • Enterprise Scalability
    • Research projects presented in class on a wide range of topics, my area of research was on scaling a PostgreSQL DBMS.
  • Database Optimization
    • particularly with MySQL
  • Error logging and messaging

I can start off by saying that not a single one of these topics came easy to understand. The one topic that came remotely easy to understand was error logging and messaging since that is the nature of my job as I described in a previous post. This is my attempt to make an over-arching analysis of what I have learned and how it will help me as I transition from school to the start of my career.

Service Oriented Architecture

An Enterprise SOA doesn’t really need an implementation. It has a lot of agility. If a certain direction is taken with the architecture, constraints are added and you cross over into paralysis. A good example of this is Microsoft Windows. In order to keep their customer base they have to, in some way, support all (or most) previous versions of their OS. Omniture has a specific architecture and business and they have to build it accordingly—their enterprise software is tightly coupled.

A service oriented Architecture is loosely coupled and highly cohesive. The elements of the architecture are modular in nature and are not restrictively bound to other parts of the architecture. Each service does one thing in one location. A service could be defined as anything that gives a response to a request to a published interface. Examples services are web services, DBMS’s, SVN, OS services, and Enterprise service bus.

Some of the technologies used in a SOA include, but are not limited to: XML, web services, SOAP, WSDL, JDBC, Java EE, J3CA, WS-BPEL, BPEJA, SLDFJO.

We concluded that SOA is a software architecture (blue print for the construction of a system) that is based on the key concepts of an application front end, service, service repository, and service bus. A service consists of a contract, one or more interfaces, and an implementation..

The web services assignment was rather difficult dufe to the fact that I had never even heard of SOAP and WSDL. I programmed mine in PHP, and after many long hours of research, help from classmates, and dabbling in different languages I was able to successfully implement my first web service.


I see Model Driven Architecture as a great way of better integrating a company’s systems with their business model. The idea of mapping out a businesses processes and then feeding it into a program that can then take those diagrams and spit out the code to get those processes integrated is ingenious. Some more of my research can be found in an earlier article on my blog.

Enterprise Scalability

Our group research project was on scaling a PostgreSQL DBMS. I had had no experience at all with PostgreSQL, but learned a lot about DBMS’s in general by doing this assignment. I understand now that to scale up a database means to tune the settings and RAID configurations, whereas scaling out deals more with distributing the DBMS to other physical systems in a cluster.

Database Optimization

This was definitely one of the more challenging projects of the semester. Granted I did put it off to finish it until the last day of class, but I did spend a lot of time during the semester trying to understand what optimizing really means. I had had trouble importing the databases Dr. Liddle gave us access to before the class period where he started showing us how to tune the queries. Most of the time in class I spent trying to figure out how to load the databases so that I could follow along with his lecture. That didn’t work, and I just got more lost after that. I figured that since other people in the class were struggling in the same area I could get together with them. When that didn’t happen I sadly realized I was on my own.

I did get quite a bit out my research, some of which I posted on my blog and all of which can be found in my final DBO assignment that I emailed to Dr. Liddle.

Error Logging and Messaging

Some of the points we made in class about what error logging should be are as follows:

  • Error messages should be human readable

· Should tell user, if not tech savvy, what to do and who to give the information to

· Clearly indicate something has gone wrong, as well as criticality

· Preserve as much of the users data as possible when the error is detected

Good error messages should contain the following:

  • Dialog box
  • Attention directing icon
  • Description, Context (ability to reproduce the error, time stamp)
  • Possible actions
  • Log messages
  • Action buttons (undo/restore…)
  • Auto reporting (send error to developer)
  • Identifier that tells you what caused the error

With the job I currently hold I’ve seen many personal applications dealing with error logging and messaging. This posting enumerates this area of my job.

No comments: