"I know everyone is getting more and more anxious to check status" of applications, read the message posted to a BusinessWeek.com discussion group by someone using the screen name "brookbond."
"So I looked around their site and found a way."
Over the next nine hours, about 150 prospective MBA students pasted a URL address into a Web browser and typed in a passcode in an attempt to learn their fates.
The consequences were severe. Harvard Business School, the MIT Sloan School of Management and Carnegie Mellon University's Tepper School of Business have pledged to reject any applicants who tried to get an early peek at their acceptance or rejection letter.
Read the rest of this story.
I'd say that's a pretty hypocrite action of those colleges, who in the past have largely neglected ethics in their courses.
Monday, March 14, 2005
Thursday, March 10, 2005
The Same Big Things
(Cross posted at my java.net blog)
The techno-clairvoyants have been strangely quiet of late... so I am left on my own to predict what "The Next Big Thing" is going to be. In the absence of prophetic visions, I think we'll have to refocus on the needs our old faithful source of income: Business.
The prevalence of computers in our society really took root with the introduction of three programming languages in the late 1950's (by a strange coincidence, I was also introduced in the late 1950's):
FORTRAN and COBOL were developed for end-users, people who needed to use computers to accomplish a task (FORTRAN for Scientists and Engineers, COBOL for Business people). ALGOL was developed for programmers, people who needed to build the operating systems and networks that executed FORTRAN and COBOL programs.
Have you ever wondered why COBOL is still powering the most important applications in many Fortune 500 companies? It's because COBOL is a fantastic tool for defining and implementing business logic in a mainframe environment. Corporate Developers need an equivalent tool for defining and implementing business processes in the Internet environment.
A Business Process definition (according to the WfMC) "consists of a network of activities and their relationships, criteria to indicate the start and termination of the process, and information about the individual activities, such as participants, associated IT applications and data, etc.”
JSR 208 (Java Business Integration) agrees with this view: "the JBI application developer is essentially modeling, designing, developing and deploying business components using vocabularies and tools that are defined by specific SE and BC implementations. The entire JBI environment is therefore one-step removed from a JBI application developer.Many such developers will be developing XML artifacts used to customize engines and bindings. This is not the traditional model of a developer as used in the J2EE and J2SE domains, where the emphasis is on development of Java code." (emphasis is mine)
The Business Oriented Language must be rich enough to describe processes that involve multiple business partners, some of whom may change as the process executes.
The Business Oriented Infrastructure must be rich enough to track each process as it executes across multiple platforms (JVMs, etc.), and provide the feedback that businesses need to tune their operations. Businesses will also demand simulators to quickly answer the question:
There is a lot of work left to do, but just imagine the impact on productivity when corporate developers can truly utilize a business process oriented infrastructure. That's a Big Thing.
The techno-clairvoyants have been strangely quiet of late... so I am left on my own to predict what "The Next Big Thing" is going to be. In the absence of prophetic visions, I think we'll have to refocus on the needs our old faithful source of income: Business.
The prevalence of computers in our society really took root with the introduction of three programming languages in the late 1950's (by a strange coincidence, I was also introduced in the late 1950's):
- 1957: FORTRAN (FORmula TRANslation)
- 1958: ALGOL (ALGOrithmic Language)
- 1959: COBOL (COmmon Business Oriented Language)
FORTRAN and COBOL were developed for end-users, people who needed to use computers to accomplish a task (FORTRAN for Scientists and Engineers, COBOL for Business people). ALGOL was developed for programmers, people who needed to build the operating systems and networks that executed FORTRAN and COBOL programs.
Computing has come a long way since the 1950s, but the constituencies acknowledged by those "2nd Generation" languages are still important to remember: The needs of people who use computers to accomplish a task are different then the needs of people who build the infrastructure.
The 3rd generation languages like Java are far richer then their predecessors, leading many of us to believe that we don't need distinct languages for users and builders any more. I suspect that belief may have caused confusion for the "builders" and unintended complexity for the "users".
SOA is a good case in point. I've heard "builders" say that SOA stands for "Same Old Architecture", meaning that there's nothing new here; SOA is just a new buzzword for marketing types.
From the "builders" perspective, this is partially kind-of sort-of true, but from the "users" perspective nothing could be further from the truth.
SOA is a architectural style that is tailored for executing Business Processes. I'm sure that the "Service" focus of the acronym is due the the suitability of Web Services as building blocks, but the whole point is to make it easier to automate Inter and Intra Enterprise Business Processes (BPOA would be a much more descriptive acronym).
"Users" (in this case corporate developers) need much different tools for taking advantage of SOA then the "Builders" who are developing the infrastructure for SOA. SOA "users" need tools geared towards defining and debugging Business Processes... and this entails much more then simply defining and processing Business Forms.
Have you ever wondered why COBOL is still powering the most important applications in many Fortune 500 companies? It's because COBOL is a fantastic tool for defining and implementing business logic in a mainframe environment. Corporate Developers need an equivalent tool for defining and implementing business processes in the Internet environment.
A Business Process definition (according to the WfMC) "consists of a network of activities and their relationships, criteria to indicate the start and termination of the process, and information about the individual activities, such as participants, associated IT applications and data, etc.”
One of the drawbacks with most existing J2EE applications is the inability to extract the Business Process and Business Rules from the running application.
The Business aspects are lost in the sea of details that make up the run-time environment. This is a huge problem for businesses; a simple change to a business process can be extremely expensive to implement.
I think that one "Big Thing" that we need is to put the "P" in COBOL (figuratively speaking): We need a COmmon Business Process Oriented Language.
We need to make a clean break between the code that implements the Business Processes and Business Rules and the underlying infrastructure. The BP infrastructure will still be written in languages like Java, but the Processes and Rules will be written in Business Oriented Languages by corporate developers.
JSR 208 (Java Business Integration) agrees with this view: "the JBI application developer is essentially modeling, designing, developing and deploying business components using vocabularies and tools that are defined by specific SE and BC implementations. The entire JBI environment is therefore one-step removed from a JBI application developer.Many such developers will be developing XML artifacts used to customize engines and bindings. This is not the traditional model of a developer as used in the J2EE and J2SE domains, where the emphasis is on development of Java code." (emphasis is mine)
The Business Oriented Language must be rich enough to describe processes that involve multiple business partners, some of whom may change as the process executes.
The Business Oriented Infrastructure must be rich enough to track each process as it executes across multiple platforms (JVMs, etc.), and provide the feedback that businesses need to tune their operations. Businesses will also demand simulators to quickly answer the question:
"What would happen if I made this change to my process?"The infrastructure that will "run" Business Processes won't be implemented in a single language on a single platform. Business Processes span multiple Business Partners; heterogenous platforms are going to be a fact of life. Many of the building blocks for this infrastructure are already in place, but the whole enchilada is far from finished.
Gregor Hohpe's ramblings are as good a place as any to see just how far we are from finishing the infrastructure that we will need. For example, today's BPM tools (like those from Oracle and BEA) almost all require a central "controller" for the Business Process, but this just doesn't match reality. Business Processes are a lot like conversations, you make an inquiry and expect a response... but that might spin off a whole new thread that you now nothing about. Building an infrastructure that can support complex processes is a daunting task.
Searching for the perfect Business Process Language is sort of like the searching for the Holy Grail. BPEL is a good start, but it still doesn't handle some common scenarios.... which is why BPMI.org and others are already working on BPXL. The Workflow Management Coalition's Extensible Process Description Language (XPDL) or UML Activity Diagrams might be a better starting point... but the jury is still out.
Bruce Silver's article "Agile To The Bone" is a very good summary of what's up in standards land.
There is a lot of work left to do, but just imagine the impact on productivity when corporate developers can truly utilize a business process oriented infrastructure. That's a Big Thing.
Update: 14Mar05 - Dick Wall has written a good article on Java Studio Creator about the advantages of having different tools for developing UIs and business logic. This ties in well with the concept of having different tools for developing Business Processes and the underlying Services.
Subscribe to:
Posts (Atom)