New Standard of System Modelling
As the business owner, you want the fruits of your IT investment to last longer and not be trapped in expensive and never-ending software redevelopment cycle. One of the underlying principles MetaBoss is built on is that the business domain and the business processes do not change as often and as radically as the information technologies do. According to this principle, MetaBoss is facilitating the creation of software systems via technology independent modelling of business domains and processes.
Consider, for example, stockbroking. The stockbroking business domain consists of clients, accounts, orders and financial instruments. What has changed in the stockbroking business domain over the last 40 years? The answer is - very little. Some more types of financial instruments, a couple of new attributes of a client, such as e-mail address and mobile phone number, would just about summarise all the changes. The main business process in stockbroking is the order flow, from the time order has been received, to the time order has been fulfilled and paid for. Again, not much has changed here. May be some more legal, compliance and risk management steps have been added to the workflow, but fundamentally stockbrokers today are still receiving orders from clients, filling them on the market, giving client a feedback about the order progress, invoicing the client when the order is done and getting paid. Has anything changed in the technology employed by stockbrokers? Everything has changed. Computers, databases, faxes, e-mails, websites, mobile phones and other technologies have changed the look of stockbroking business beyond recognition, but have done little to its substance.
Let's take the stockbroking example further. Consider a technology independent document, such as a plain English handbook versus a Computer program. For how long such a handbook which describes client, account and order records would survive on stockbroker's desk and be useful? With a few small scribbles (i.e. add e-mail address to client record) - for a long time. And for how long would the ASSEMBLER definition of the same information survive? How usable will it be even to software professionals today? Obviously it will not be very suitable and practical after a few years since it was done.
This is what the Model Driven Design and Development is all about. This approach uses technology independent descriptions and pictures of business data and processes (i.e. models) to design and store as much information about business as possible. MetaBoss will read these models and automatically build the systems targeting a particular set of technologies which are the flavour of the day. Tomorrow, when World Wide Web will disappear and DUMB (Digital Unobtrusive Mind Beaming) or some other technology will be in favour, MetaBoss will read exact same models and build the systems targeting the new set of technologies.
The Model Driven Architecture (MDA) concept has been formalised and standardised by the Object Management Group (OMG). OMG is a not-for-profit organisation developing "technically excellent, commercially viable and vendor independent specifications for the software industry". More information on the OMG and MDA approach can be found at www.omg.org.
MDA is gaining momentum and is fast becoming commonly accepted practice. Sun Microsysems has published standards and created some reference implementations which mapped MDA to Java world. MetaBoss is fully compliant with these standards. Even better, MetaBoss is actually built on top of the Netbeans MDR (stands for Meta Data Repository), which is a an open source project supported by Sun Microsystems. This makes the MetaBoss definitions open to third party modelling tools via XML Meta-Data Interchange (XMI) specification.
In general, the MDA compliance and XML Meta-Data Interchange capability is very important consideration for potential users of modelling tools. The reason is that your investment in the models is far better protected with a compliant tool, since models can easily be exported and transferred to a different toolset.