Tools Alone Produce Fools

Managing a project or defining a complex system requires the knowledge and skills of appropriate methodologies and processes to realize the objectives. An individual who only knows how to use a project management tool (see selected list of tools in the sidebar), but lacks the understanding of the iterative and progressive nature of projects and how to manage the different processes within each phase will not be able to lead a successful project.

There is a big difference between developing a schedule that works and a schedule that looks good in a tool. Expert project managers need nothing more than a pencil and sheet of paper to lead a project. Tools help automate calculations and enable updates and corrections easily, allow tracking of changes and ensure a controlled environment that is agile and flexible. Tools do not defie methodologies, approaches, strategies, or plans. Tools do not execute, monitor or control and tools do not communicate, coach, inspire, motivate and collaborate. Only project managers do.

Are your pencils sharpened?

High Availability Systems Failure

Does your business require availability capabilities? In today's complex business landscape and the demand for high accountability and transparency, high availability becomes a basic requirement in operations, information access and decision-making.

Interestingly most high availability environments that fail are unable to deliver the expected results no because of technology immaturity, but mostly due to poor management and oversight. A publicly known example is the State of Texas data loss as a result of invalid checks and balances and inappropriate technical management. In this particular case according to the article in the Dallas Morning News IBM has been fined $5.4 million. Of that, $2.7 million was for failing to resolve problems quickly and $1.2 million was for server outages. Data backup breaches, missed mail deadlines and taking more than 15 minutes to respond to serious incidents accounted for the rest, according to department records released this week.

Next time you implement a high availability solution, do not get fooled by the latest server technology, data backup system or disaster recovery tools. A high availability technology with a staff member who can not use it makes it useless.

Maryland is First in the Nation to Reach Recovery and Reinvestment Act Milestone

States are required to meet certain federal guidelines and requirements to be eligible to use recovery funds allocated to the State. On March 23rd, Maryland reached this milestone. According to the State of Maryland Governor's website, "Phase I of Maryland’s ARRA funded highway projects totals more than $224 million and has the potential to support up to 10,000 jobs".

On the top of President Obama's priorities are business integrity and fiscal responsibility. Vice President Biden has been assigned this responsibility. This will drive the need for certified project managers and professionals by contractors to ensure best compliance possible with sound business practices and accountability standards.

This is a great time to get PMP certified for professionals interested in pursuing recovery act projects. I am offering several workshops soon.

Risk Management Through Coaching

To manage risks on a project we tend to follow various processes such as planning for risk management, conducting qualitative and quantitative analysis, and responding to risk. These processes include specific details such as the definition of a risk, risk triggers and thresholds, steps the team will take to identify risks, the classification and groups of risks, risk prioritization and many other little details. These processes work very well - when implemented correctly of course - and are successful in avoiding the negative consequences of a potential risk should it occur.

Besides these well known and understood project management, agility or systems engineering processes, coaching and mentoring is another powerful tool for risk management. Having another project manager as your coach allows you to get a fresh insight on project health and can hold you accountable in an informal manner to project goals and aspirations. Your coach acts as a friendly auditor and makes collaboration even fun.

Next time you manage a project don't forget to have a coach or buddy, whom you trust. You will not only gain some insights on your progress, but you will also be motivated to raise the bar.

External Project Risks More Important than Ever

As the economy becomes more challenging and the impact of globalization increases project risks become more in number and impact. Moreover external risks are closer than before. Examples of external project risks that have become much more visible during the downturn and that project managers should start accounting for if they haven't already are:

- Fluctuating currency exchange rates
- Labor issues (strikes, layoffs)
- Regulation changes
- Customer investment and purchasing changes
- Contract breaches
- Financing and investment opportunities

3 Ways To Guarantee a Failed Product

I was at the county jail a few weeks ago coaching a group of young men on strategies to transition back into society. I asked them two questions, the first list 3 goals you would like to accomplish during your lifetime, things you will be proud of in the hereafter. They jotted down some goals on 4*6 cards. The second question was list 3 things that if you do, you are 100% sure that there is no way you can achieve these goals, it will be impossible to achieve them. I gave them a few minutes and they all had a few points to share.

One example of a goal that was shared was to get back to education and enroll in college, get a degree and be a productive member of the society. The young man noted involvement with illegal substance to be a factor not allowing him to realize this goal.

Developing successful systems follow the same pattern. We need to understand user requirements, the utility of the system, why is the system needed, what value is the system offering, the gap it is filling. Once that goal is clear and understood, we need to make sure we protect these requirements from "outside noise", what is also known as scope creep. Scope creep is for sure a main reason why projects fail, it is when we add requirements, remove requirements, or just change requirements in an uncontrolled fashion, without going back to understanding the rationale and true value for doing so and relating it to the project's objective, cost and schedule.

Reason 1: Low Quality Requirements and Scope Creep - Uncontrolled Changes

A second young man in the group shared his goal was to be a successful businessman offering valuable services to the society. He noted down that unethical dealings would be a reason to ensure he never accomplishes his dream. I advised him that to overcome this hurdle he needs to continuously gauge his relationship with his Lord and measure his values and ethics. If he notices that his relationship is getting weaker, he needs to take corrective actions.

In the domain of systems development we call that validation and verification. Is the project still valid? i.e. is it still delivering what it was originally intended to deliver. And is the work correct? Can we verify that the work is what was expected earlier at the beginning of the project, through testing, and if it is not correct, can we take corrective actions to resolve defects. This validation and verification needs to be conducted throughout the whole life cycle of the product, and not just near the time we turn it over to the client, otherwise the deviations from the expected results could be huge, leading to costly modifications, schedule slippage and possibly a failed product.

Reason 2: Not Considering Validation and Verification Early in the life cycle of the product - Developing the wrong product, or developing the right product incorrectly

A third person shared that his goal was to be a teacher, nurturing young minds not only with knowledge but the application of the knowledge and its purpose. I reminded him to share with his future students trace back the purpose of the knowledge they learn from him, to the purpose for which we were created. Everything we do needs to serve the purpose for which our Lord created us.

Similarly, in the domain of product development, we can that requirements traceability. How do the original requirements defined by the client relate to design work, development work, testing and final product features. It is important that throughout the life cycle of a product we maintain a clear trace of how the work we are currently involved in relates back to what the customer needs.

Reason 3: Poor Requirements Traceability - Missing some Requirements in Implementation, adding Features not Needed, or both


Make sure if your customer asks for a mule, you deliver a mule as expected, and not a cow. Although a cow has plenty of benefits and utility, it might not serve the need satisfied by a mule.

7 Tips for Engineering Students

I often get questions or concerns from engineering students about studying and being able to pull through college to reach their goals of becoming engineers. I have to admit going through engineering school is no light challenge, but at the same time it is an enjoyable experience.

Common comments are concerns of not being able to understand the questions in an exam, or not able to go through the needed steps, or just finding subject matter too complicated.

Here is my advice for of these folks and other future engineers.

1. Understand that engineering is all about problem solving for the betterment of humanity, through the use of scientific facts. This means that a good engineer must,

• understand what the problem is (how it happens, why it happens, when it happens, where it happens)
  
• analyze the problem - visualize it (use a pencil and paper to sketch, engineers are born to sketch)
  
• determine its scope - (how big is the problem, who does it affect, under which conditions)
  
• determine what information is given to us (data, assumptions, facts)
• learn the sciences (calculus, physics, chemistry, etc..) to use in problem solving
• apply these sciences to the appropriate solutions for the relevant problems

2. Never memorize, engineers are thinkers. Anything you learn must make sense to you. You must understand why a theorem or rule is the way it is, how it came to be so, this will help with critical thinking, and will enhance information retention.

3. Do not depend on calculators too much, understand how calculations occur, understand how the value for the various engineering functions are calculated, the meaning behind a differential, or integral, etc.. Then use the calculator to just speed up calculations - remember a fool with a tool is still a fool.

4. Develop mini-processes for yourself of things to do when you analyze engineering problems, make these processes adaptive to suit your thinking styles, analytical abilities and memory capabilities.

5. Practice makes perfect. Just like spending ours in the gym pumping those muscles up, or on the court perfecting those slam dunks. Engineers need to practice solving various types of problems (easy one, long, ones, short ones, complex ones, complicated ones, straight-forward ones, etc...).

6. Be organized - learn how to manage real-estate space on your paper. Organize data, analysis, scratch notes, results, conclusion in clear separate sections of your sheet. Be a good communicator, improve your writing and verbal skills, to allow you to effectively communicate your solutions to others.

7. Love the subject matter. You can never solve a problem, you don't care about. A good engineer can never design a bridge if he cares more or less of the importance of crossing the river. Love it, adore it, live it, immerse in it... be the engineer !!

Iterative and Incremental - We Have Something to Show

On projects which follow a waterfall methodology and run into project delays, usually there is nothing to demonstrate to the client. This is a little different with iterative and incremental methodologies. Iterative meaning we repeat the life cycle processes over and over, with an incremental addition in each run. With iterative and incremental development a delayed project can demonstrate an artifact to the client. It might not be everything the client wished for, but it is there.

Iterative and incremental methodologies provide higher levels of confidence to project sponsors, who would be more willing to extend investment in a troubled project than a project with no output at all.

Agile methodologies embed iterative and incremental approaches. Examples are Rational Unified Process (RUP), SCRUM, XP and others.

Great leaders know how to scope these increments and how often should they come out. For example lets consider a generic problem well know to everyone, the current economy down fall. This problem does not have a one shot solution. A $700 billion stimulus plan will not solve it for once and for all. It is just an iteration that will yield some results in 18-24 months, to keep things afloat. Most probably another iteration will be needed to sustain some of the new initiatives started in increment 1, and so on.

We apply iteration and increment processes in our daily lives as well. When we go to the grocery store to purchase soup, we don't purchase 100 cans of soup for the full year, even if we could successfully store them and pay for them. We purchase maybe 5 or 10 cans for a week or two, we then repeat the grocery purchasing process in one or two weeks.

Reasons for iteration are many,
(a) gain confidence in an experience to decide whether to repeat it or sustain it or not
(b) streamline cash flow
(c) simplicity
(d) effective time utilization
(e) limitation in resources
(f) shorter demand cycles (time to market, constituent demand, etc..)

Effective Project Management in a Snipit

What are projects all about? A project is about delivering capabilities on time and within budget. So you are hired as a project manager at company ABC to ensure that their new product can be developed within the next six months and within budget as defined by the product team.

To ensure the delivery you need to accomplish a few basic items. Most people don't even do this bare minimal checklist below.. and guess what they wonder why their projects are among the 60%+ statistics of failed projects.

a) Understand the problem/gap the product is offering to solve (ie understand the value of the end product)
b) Define the project scope (schedule, cost, capabilities, stakeholders, assumptions, dependencies and risks)
c) Put together a good team that compliments each others skills, abilities and knowledge.
d) Define all work items that are needed to make the capabilities (product) delivered, in a hierarchical format (aka work breakdown structure - WBS), detailed to a level that can allow weekly reporting on the status of work completed
e) Define activities and their duration and resources needed to accomplish the work defined in the WBS, and come up with a schedule and cost budget.
f) Track the work completed relative to the cost and time spent to date and as planned. Are your cost and schedule variances healthy?
g) Know and track your risks throughout the project and mitigate as your move forward.
h) Ensure changes are controlled and tracked along with risks, issues, cost and schedule health.

You can be comfortable that you have a good chance of delivering your end product. Of course there are other details, but for the most part this is the backbone, if its solid, your project should be able to make it to the finish line.

Volunteer Team Members on Your Project?

Have you ever run a project that is solely or mostly running on a project team of volunteers? I was presenting to a group of program directors in the research field. Their dilemma is that they manage projects which have team members fully run by volunteer researchers from other organizations.

After comforting them that they are not the only people in the world that run projects fully dependent on volunteers, but rather they are part of the millions of teachers, religious groups, social service groups, civil rights, good citizens, and dozens of professionals who donate their time and expertise for the good cause of the World .. they became more relaxed.

So back to their challenge... How to get a volunteer - someone who is not paid, not officially or legally bound, not under your authority or control - to do their part on the project as a team member?

Answer is simple: Motivate and ensure the value they are interested in by doing this good will is present and did not disappear.

I have managed and coordinated tons of projects such as the one we are talking about. I also participated in tons where I was a team member. Bottom line --- as long as there is volunteer value. They will not only stick around, but will produce exceptional value... let it evaporate and before you know, they are all gone.

Example: Project X: Goal is to initiate, launch, implement and supervise a series of monthly community dinner at a Muslim community. Volunteers who are interested in being part of this project will most probably join for one or more of the following reasons,

a) they like food, food events, cooking, or have some passion to food
b) they like social gathering and chatting with others, like to be part of a group, or big family
c) they respect organization and like to see these events well organized and a god experience for every one
d) they just want to help out a community they belong to and enjoy being part of

So as a project manager, you know that all these volunteers are not getting paid, have very limited time, might live far away, but are interested in helping out, because they told you. As long as those 4 items above are maintained, they will keep coming. Now when something happens and for example these volunteers are no longer allowed to cook and bring in their own meals to share with others... they will not come because point a) is not longer available. Or if they feel that participants dont get along together and some tensions arise then they will stop again because point b) is no longer available... and so on.. you get the point.

So in a nutshell project manager need to have strong emotional intelligence skills and keep their eyes and ears open to what the volunteer team members are interested in and how much of it is on their projects.

Back to the volunteer researchers from all across the country that are on Bob's project (not real name). As long as the researcher's can add their work to their tenure requirements, paper portfolio, get academic recognition, be known as a participant, be respected for their knowledge and ideas, be able to have open communications with other scientists..... they should stick around.

Successful teams develop because they strive for the carrot, regardless what form the carrot takes.

Enterprise Architect vs. Service Architect

If you open any book on SOA you find it defined as an architecture which offers a framework for improved business - technology alignment. In [1] SOA is defined as "a framework for integrating business processes and supporting IT infrastructure as secure, standardized components - services - that can be resused and combined to address changing business priorities". The IBM SOA Foundation [2] defines SOA as "the practice of deriving an information system design from a business design".

I find both definitions to be confusing and incomplete. The first definition is basically an enterprise architecture (EA) framework, right? The definition that it is a framework means that it defines governance, perspectives (views) and/or some methodology. Similar to TOGAF, or Zachman (does not have a methodology) or other well known architectural frameworks. TOGAF which is a framework for enabling the design, evaluation and build of the right architecture for an organization [3] offers an enterprise macro level architectural definition. TOGAF defines four main domains - business, data, application and technology. Well, the answer is not quite right. SOA is not EA, SOA is applicable at a level lower than the enterprise, it is focused on the service level, wherever it might be. In some cases services could be enterprise-wide and high level, but most of the time it is local.

Lets think of SOA as the "service instantiated" architecture for an enterprise architecture. To make it easier to understand lets take the example of a small non-profit community center. An enterprise architecture for this community center is the evaluation, definition, design and build of an integrated structure unifying the community center to allow it to achieve its mission. For example an enterprise staff appraisal system as part of that architecture. On the other hand SOA will define how the various services related to a staff performance system can be designed in IT resources and aligned to the business goals. Services could be "Staff Feedback Solicitation", "Performance Appraisal Metrics Definition", "Performance Appraisal Metrics Assessment", and several more. So in a sense SOA is addressing the question of "now we have an enterprise wide structure and method to appraise staff performance, how can we actually turn it on, and customize it for different departments, with optimum reusability of approaches and resources.

Other definitions of SOA is that is it is "a methodology and approach that can be utilized to deliver or to support an enterprise architecture initiative" [4].

______________________________________________________________
[1] Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones and Rawn Shah, " Service-Oriented Architecture (SOA) Compass: Business Value, Planning and Enterprise Roadmap, IBM Press, 2006.

[2] Rob High, Stephen Kinder and Steve Graham, "IBM's SOA Foundation: An Architectural Introduction and Overview", IBM Business Consulting Services, Version 1.0, Nov 2005.

[3] The Open Group, "The Open Group Architectural Framework (TOGAF)", Version 8.1.1, Enterprise Edition, 2007.

[4] Niel Maehiter, Quote in an Article titled, "What's the difference between SOA and enterprise architect?" by Joe McKendrick, June 11th, 2007. (link)

Metrics for Defining the Complexity Level

I was sitting in a meeting when a whole bunch of folks started sharing ideas on how to assess the level of risk associated with a project or system under development (SUD). Some thoughts were to consider the number of requirements, others the number of change requests needed, and some suggested the level of engineering support needed for a requirement to be realized, for example does the requirement call for an architectural change, design change, development change, or just test or only support during testing.

I agree with the last proposal, analyzing the scope of changes is a good way of defining the complexity and hence the risk of the project, then we can create metrics that reflect these different levels of engineering support. Merely looking a total number of requirement, change requests or development teams involved might not provide the most accurate assessment. Instead, the system architecture needs to analyze and study the requirements impact and assess design complications, development challenges, testing validity and deployment issues. This integrated view can provide a more objective feel for the level of complexity involved in the SUD. A system might have only two system level requirements that drive the whole architecture change and hence brings in large design, development, testing, deployment and support efforts, compared to another system which has 2 dozen requirements which marginally impact development and will hence have a much lower effort in other areas and less overall complexity and risk.

I came across some interesting articles and papers on this topic.

A Complexity Assessment Methodology for Programmable Electronic Mining Systems
Software Complexity Measurement
Design Complexity Measurement and Testing
A Function Point Method for Software Complexity Measurement

How do you assess the complexity of a project in your environment?

A System for Complex Event Management

It is expected that about 2 million individuals will visit Washington DC on Jan 20th. This will not be the largest event that draws pedestrian traffic. Each year Saudi Arabia hosts over 3 million pilgrims in Makkah and its surrounding areas for the Hajj worship activities. The Saudi's can attest that is is by no means an easy job, to keep the crowds safe, moving and able to do what needs to be done with ease.

The inauguration is a little different and less complex that Hajj in a sense that the largest part of the event is confined to the Mall and mostly static - i.e. folks are sitting or standing to witness the President as he gives his speech. Whereas, the Hajj is a more dynamic experience. Pilgrims move back and forth between Makkah, and the nearby mountain of Arafat and the valley of Mina on the outskirts of Makkah, 8 km away. Among the pilgrims are also celebrities such as Presidents and leaders of Muslim countries, businessmen, athletes, scholars and other well-known public Muslim figures who have intended to perform their pilgrimage. So the complexities of the inauguration might be much simpler than that of Haj, yet the organizers and teams overlooking its management have put a great deal of effort in organizing it that is worth discussion.

I share a few images - courtesy of the Washington Post - of how the event is organized illustrating security checkpoints, seating areas, entrances, exits, rest areas, vending, etc.. You can call these mission diagrams or context diagrams, at the end of the day the represent the high level architectural overview, which is worth appreciating as it reflects the amount of effort out into managing an event effectively.

The Saudi Government as well has recently taken extra ordinary measures to control the Hajj traffic and ensure safe experiences for the pilgrims. What is interesting is that the Hajj planning never required the closure of any streets in Makkah near or around the Holy Kaaba, unlike the inauguration plan, nor has it required security checkpoints such as those in the inauguration, other than guards at the entrance of the Grand Sacred Mosque for visual inspection.

This is a very interesting domain that is worth research, and I am sure there is a lot to learn from both the Saudi and American experiences.

Update: 3/22/09 - There is a discussion on linkedin related to major event management, you can follow it here, if you are member of "Project Manager Link" group.

Is there a difference between a SOA repository and a SOA registry?

Generally speaking a registry is a location that stores information about registered entities. A few of examples of registries could be a town's birth registry which records all births in the town, a College class registration office, and an annual article index of a publication which lists all articles that appeared in the publication during a particular year.

Registry is defined in the Webster's College Dictionary as the "place where a register is kept", and the dictionary defines register as "a book in which records of events, names, etc., are kept".

In the examples provided above we see that the birth registry will contain a list of all names of people who were born in the town, their dates of birth and maybe some other information like the address at the time of birth, ages of parents, names of parents, etc. We do not expect to see the actual people in the registry ! The people will be in their offices, homes or wherever else.

Similarly, in the case of the annual article index, which is another form of registry we expect to see the titles and dates of publication of articles that appeared in the publication during that year. We do not expect to find the articles themselves in the index of articles.

A repository on the other hand is a location where actual artifacts are stored. We can guess that for the example of the birth registry, the actual repository would be hospitals, delivery clinics and places where people give birth. This is where we can actually find the babies.

Similarly in the case of the article index, the actual articles would be find in the various issues of the publication throughout the year, and would be stored in a library.

Repository is defined in the Webster's College Dictionary as " a place where things are deposited, stored or offered".

So now in the context of SOA, we can define the Service Registry and Service Repository as follows.

Service Registry
A comprehensive list of all SOA services available to an enterprise to achieve a business objective. The list would include the service identification information, location of the service, service classification (purpose), and information about how to interact with the service.

Service Repository
A storage location that houses the SOA service and its components, is involved in controlling access to the service and the presentation of the service to its users

If we ponder for a moment we notice that some key areas of a SOA service are neither part of a service registry or service repository - at least by defintion. For example a service's history, statistics about the the service, performance reports, etc.. by definition are not part of the repository. Some SOA implementations or frameworks might decide to store such service management reports and information in the repository, others might wish to develop a SOA Service Management Repository which will house that kind of informaton.

Systemic Reflections from the Obama - McCain Race

There is no doubt that Obama not only won the elections, but also smashed his opposition. Looking at the Electoral votes we see a torrent gap 349/163 and a popular vote of 53%/46%... what a surprise... totally unpredictable... I personally thought he might win 51%/49% and maybe an electoral vote ratio of 1.1/1... not 2.14/1..

So this tells us that human systems are totally unpredictable.. engineering a system with a human as part of it might be suicidal in some cases. So lets take the example of engineering a commercial aircraft, is the pilot part of the system or not? Most system engineers will say.. not really ... the system is the plane (structure, mechanical, electrical, etc..) we can model those, but we can't model the pilot, what if the pilot is too slow to land, or fell asleep during take off.. so many soft factors to model, so lets take the pilot out of the picture.. and then we test (verify) out plane with an average pilot... that is a pilot who did not have a bad day, did not lose a loved one the week before, is not tired, has no spousal problems, etc.. So the test passes, aircraft declared ready for production, sold and used for years, without a hitch...

We recall the Egypt Air flight than mysteriously dropped out of the Eastern US skies on Halloween night 1999, until our date we have theories and thoughts of why the sky bus blew up and perished in the air... some say the pilots walked out of the cabin to stretch, when the senior pilot walked in and committed suicide, other theories are cracks in the wing, a third fuel leakage, and a fourth contribute the root cause to a strike 10 yrs ago when that batch of 747s where in Seattle on the assembly line, and that because they were not in a good mood the quality of manufacturing standards was below nominal.. who knows.. it could be all the above, or none of the above.. bottom line is that many of these root causes include a human factor.. totally unpredictable .. just like the American voters.. the time has come to include soft factors into engineering problems -- Point 1... we can't ignore soft factors

Now, wasn't it the McCain campaign that distributed those millions of DVDs in swing states to tell them about how radical Islam is? Covering up truth, and smearing others does not work anymore... the people are more educated nowadays than the 80s, 70s, and 60s.. thanks to the so called Internet, and its myriad of facebook, you tube, google and countless other applications.. --- Point 2... Fooling customers never works, eventually they will know that you are marketing a 747 and selling a prop.

Finally, end users buy and use what they want, not what you tell them they need... Americans don't want their daughters and sons in Iraq, Americans don't want their 401Ks wiped out, they don't want to lose their jobs, telling them that pulling out of Iraq is not only stupid, but irrelevant.. regardless whether it is a good idea or not, its not what they want to hear. End users want to hear solutions to their problems, they don't want solutions to other problems, and they are not smart enough to know where root causes come from, you where there when the plane crashed.. then you must be involved. --- Point 3... It doesn't matter how brilliant or great your idea is, if it does not solve my problem, its worthless in my perspective [1], also I don't care why the system crashed, the point is that you did not do a good job designing it. Don't blame the storm, blame the plane [2]

We can wish as much as we want, model as much as we want, take the means, but at the end whatever Allah ordains will happen...

Now whether Obama will deliver on his promises is a completely different story, history will let us know.

SOA Programming Allows Independence

The SOA programming model is to embrace underlying programming languages that are already deployed in the enterprise. It does not mater whether applications are .NET, CICS, Java, SAP based, or based on any other technology, these technologies are all transparent to SOA.

SOA allows the architect to hide any variations or differences between languages and programs to maximize reuse. Additionally we can drill down into unique aspects of a specific language or program only when needed, without exposing the details.

One of the major benefits of this programming model followed by SOA is to program and develop business and service design rather than a technology. For example the programming focus would be on a student grade verification process, rather than a .NET session.

Any experiences to share?

XML's role to SOA

SOA leverages the standard XML data representation to reduce underlying complexity of application environments. Some are examples are;

- Passing XML documents and schemas between applications allows for the standardization of data format and type, which this improves predictability and performance.

- XML documents are easily understood by different stakeholders such as architects, analysts, developers and users, leading to enhanced data maintenance, traceability and clarity.

- XML allows the support of standardized vocabularies across the enterprise, hence reducing mis-interpretation of corporate data and data models.

- XML allows a SOA based system to realize a foundation data representation and data management layer.

For SOA to leverage the benefits of XML, a solid XML architecture should be developed and implemented. Such architecture should include architectural components for data transport, structure, validation, verification and modeling. Accommodations for RPC-style messaging needs to also be considered if an environment does not support document-style messaging (SOAP). In such cases we need to ensure no conflicts exist between usage of RPC-style SOAP messages (from shaping XML documents around a parameter data exchange model).

A Slotting System for Misery, Poverty and Crime

It was a bit of a shock to see that Marylanders favored bringing slot machines to Charm City, and its suburbs. It is no more than a call to bring crime, prostituition, and long term economic failure. This is not just my opinion as a Muslim Systems Engineer, but that of any person who has some basic knowledge of economics and social reform will have the same opinion.

What comes easy goes easy. Slots brings a system of vapor to Maryland. No true productivity, no true growth and no true value proposition, other than greed to the operators.

We should not be surprised to see more bankruptcies, shattered households, and chaos similar to the global financial crash pretty soon in the Free State.

Should Systems Engineers Study Psychology?

Given the fact that systems engineers deal with systems, and most systems comprise of a human element in it, it seems to make sens that systems engineers need to know a little about how people act.

Humans are very complex system components, they can be viewed as a system in themselves (human system), or even a system of systems (SoS) (digestive, neural, circulatory, psychological, muscular, etc..)

So maybe after all those biology classes we used to study in middle school do have some benefit to enterprise architecture. I guess systems engineers who are involved in soft system should study not only psychology, but maybe also other human systems of interest to the largest SoS.


I came across an interesting article at http://www.techjournalsouth.com/news/article.html?item_id=6299 which discusses cognitive systems engineering, which is defined as, "A combination of psychology, anthropology, computer science, design and systems engineering, the field of cognitive systems engineering is the understanding and designing of systems that require human intellectual work".

Got to go dig those science books..

So What are the Services in SOA?

Service-oriented architecture has gained heavy adoption over the past few years. The next several postings will provide a high level SOA introduction. I am hoping the posting could serve as a basic primer for systems and project professionals working on a SOA project.

What is service-oriented architecture?
An architecture that allows the alignment of business processes and objectives to Information Systems in a flexible and adaptive manner, through the defintion of services.

What are these services?
Services are modular and repeatable business processes. A service could be defined at different levels of the organization. for example, a "customer update" could be a service that allows a customer to update their profile. On another level, a subscriber authentication process - to allow customer to gain access to her profile to update it - could be a service.

What are the main characteristics of a SOA service?
Services are also loosely coupled, maintaining a relationship that minimizes dependencies and only requires the awareness of connected services. Services are stateless and minimize information related to a specific activity.

So some examples of simple services in a sales department of a business could be; "collect customer information", "collect product /service information", collect payment terms". Each of these services could be broken down further as needed